01 · 工程方法论全景：前端转 AI 全栈的做事地图
这是工程方法论全系列的第一篇。 它回答三个问题：为什么"会做事"比"会某个技术"更保值；做一件事要经过哪些环节；每个环节对应 F 域哪篇文章、需要什么等级。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 给"做事"本身画一张地图：从需求到交付的完整环节、每个环节的方法论，以及初中高资深四级能力 |
| 核心内容 | 方法论与技术的区别、六件事的完整闭环、深度三层、等级四级、F01~F07 文章地图、按角色学习路径 |
| 读完能回答 | 为什么方法论更保值？做一件事要经过哪些环节？我现在是什么等级，下一步该看哪篇？ |
| 相关板块 | F02 · 需求拆解 ｜ C00 · 后端学习全景 ｜ G04 · AI 编程与研发提效 |
一、先回答"为什么方法论更保值"
技术栈三年一变：三年前在写 jQuery，今天在写 Flutter；昨天在用 PostgreSQL，明天可能在用向量库。但把一件事做好的方法——先弄清目标、再拆任务、先测量再优化、出了故障能定位根因——二十年不变。
方法论 = 不依赖具体技术的决策能力。 前端、后端、AI 三套技术差别很大，但它们共享同一套"做事闭环"：
text
需求拆解 → 技术方案 → 技术选型 → 开发实现 → 调试排障 → Code Review → 性能优化
F02 F03 F04 (各域) F05 F06 F07结论：前端转全栈，技术可以边做边补（各域文章负责），但方法论应该先建立——它是你在陌生技术里不迷路的导航。
二、六件事，一条闭环
工程上的大部分问题，都出在"跳过了某一环"。把每一环的方法论补齐，整个闭环才算成立：
| 环节 | 要回答的问题 | 对应文章 | 常见跳步后果 |
|---|---|---|---|
| 需求拆解 | 到底要解决什么问题？ | F02 | 做出来的东西没人要 |
| 技术方案 | 怎么做、为什么这么做？ | F03 | 边写边改，返工 |
| 技术选型 | 为什么选它、不选别的？ | F04 | 用了不合适的轮子，重构 |
| 开发实现 | 怎么写对？ | 各域落地文章 | — |
| 调试排障 | 出问题了怎么定位？ | F05 | 瞎改试错，耗时且引入新 bug |
| Code Review | 别人能不能看懂、接手？ | F06 | 代码只有自己能维护 |
| 性能优化 | 慢在哪、怎么量化？ | F07 | 凭感觉优化，越优越糟 |
前端转全栈尤其容易踩两个坑：一是"只做实现"（跳过 F02/F03，拿到需求直接写代码）；二是"只懂单端"（不会把调试、性能、评审的方法迁移到后端）。F 域就是把这两块补上。
三、深度三层：哪些要深入、哪些掌握、哪些了解
方法论和知识一样，需要分深度投入时间。不是每件事都要做到资深：
| 深度 | 含义 | 必须做到的方法论 |
|---|---|---|
| 深入 | 不查资料能独立完成 | 需求拆解、调试排障、Code Review、技术方案写作 |
| 掌握 | 知道原理、能带队执行 | 性能优化闭环、技术选型的正式流程 |
| 了解 | 知道存在、需要时能组织 | 工程文化治理、团队级流程设计 |
判断标准："不会这个会不会出事"。不会拆需求 → 会做错方向（深入）；不会写方案 → 大型改造做不了（深入）；不会性能优化 → 慢的时候能查就行（掌握）。
四、等级四级：初中高资深
| 等级 | 能力标准 | 对应文章 |
|---|---|---|
| 初级 | 能把模糊需求拆成任务、会系统化排障、会写能被读懂的代码 | F01、F02、F05 |
| 中级 | 能写可评审的技术方案、做有效的 Code Review、独立交付模块 | F03、F06 |
| 高级 | 能做技术选型与性能优化的完整决策闭环，能对方案负责 | F04、F07 |
| 资深 | 能主导跨团队协作、为长期演进做取舍、建立工程文化 | F03~F07 综合 |
四级不是"学完初级才能碰高级"。做个人全栈项目时，你可能同时需要"初级的需求拆解 + 高级的技术选型"——那就并行推进，不必串行。
五、F01~F07 文章地图
text
methodology/
├── 01-工程方法论全景 全景入口：深度三层 + 等级四级（本篇）
├── 02-需求拆解 从模糊需求到可执行任务
├── 03-技术方案写作 需求 → 设计 → 评审的文档实践
├── 04-技术选型 框架 / 中间件 / 工具的通用决策框架
├── 05-调试方法论 从症状到根因的系统化排障
├── 06-CodeReview 怎么看代码、怎么写评论、怎么建流程
└── 07-性能优化通用思路 测量 → 定位 → 优化 → 回归 的闭环自检清单
- [ ] 能说清"方法论"和"技术"的区别，并给出一个跨技术不变的例子
- [ ] 能画出一件事从需求到交付的完整闭环，指出本域文章落在哪一环
- [ ] 能给"需求拆解/调试/Code Review"标注正确的学习深度（深入）
- [ ] 能说出自己当前的能力等级，并选出一篇下一篇要读的文章
- [ ] 能说清 F 域与 A/C/G 各域的分工，不把方法论文档当技术教程用
常见误区
| 误区 | 事实 |
|---|---|
| "方法论是虚的，技术才是实的" | 技术会过时，方法论才是把技术用对的底层能力 |
| "会写代码就会做事" | 写对只是其中一环，方向、方案、排障、评审同样重要 |
| "方法论是管理者的东西" | 初级开发者的需求拆解与调试，同样依赖方法论 |
| "F 域是各域技术的汇总" | F 域只讲通用做法，具体技术链回 A/C/G 各域 |
动手练习
练习 A：画自己的做事闭环
回顾最近完成的一个功能，写出它经过了闭环的哪几环、跳过了哪几环；跳过的环节分别导致了什么问题。
练习 B：给自己定等级
按第四节的能力标准给自己打分，列出"最强的一环"和"最弱的一环"，并把最弱一环对应的文章排进本周计划。
练习 C：找一个跨技术迁移案例
选一个你在前端用过的方法（如"先复现再修复"），想清楚它如何在写后端接口、调 LLM 时同样成立。
相关文档
本区
- 02 · 需求拆解 —— 闭环第一环
- F 域 README —— 工程方法论索引
其他域
- C00 · 后端学习全景 —— 后端知识地图，与本文的方法论地图互补
- G04 · AI 编程与研发提效 —— AI 如何辅助人把事情做得更快
- IH · 软技能与行为面试 —— 面试表达 vs 真实做事，二者不同