我并不是最近才开始用 AI 协作开发的。过去 1 到 2 年里，我已经陆续把 Ollama、Copilot、ChatGPT、Claude、Claude Code、Codex、Trae、Cursor 等工具带进日常工作。但如果回头看，之前更多还是停留在“解决具体代码问题、提高开发效率”的层面。直到最近两周，我才第一次明显意识到：AI 真正更大的价值，不只是帮我写代码，而是开始进入方案、交接、复盘和方法沉淀。这也是我决定开始系统记录这件事的原因。
我并不是最近才开始用 AI 协作开发的。
如果按我自己的实际体验来算，我大概从 2024 年下半年开始，才真正把 AI 更频繁地带进日常开发里。
最开始那一波比较明显的触发点之一，是 Llama 3 在 Ollama 上可用之后。后来我又陆续接触和使用了更多工具：Copilot、ChatGPT、Claude，再到后面的 Claude Code、Codex、Trae、Cursor 等等。
也就是说，严格讲起来，我用 AI 协作编程这件事，已经有 1 到 2 年了。
但过去这一段时间里，我对 AI 的使用，更多还是停留在一个比较直接、也比较常见的层面：
- 帮我查资料
- 帮我解释报错
- 帮我生成局部代码
- 帮我更快解决某个具体开发问题
- 帮我提高当下这一次任务的效率
这些当然都很有价值，我现在也仍然在用。
只是如果回头看，我会觉得那时的自己，更多还只是“会用 AI”。
我满意于它能帮我更快解决代码问题、提高开发效率，也确实从里面得到了不少帮助。
但那种使用方式，本质上还是偏局部、偏即时、偏工具化的。
我并没有进一步去想：
- 它能不能进入更完整的项目流程
- 它能不能帮助我做方案，而不只是生成代码
- 它能不能帮助我沉淀交接、复盘和模板
- 它能不能让我形成一套可复用的工作方法，而不只是单次提效
真正让我开始认真重新看待这件事的，是最近这两周连续的真实项目实践。
过去两周，我在项目里密集地做了一轮这方面的尝试和沉淀。也是这一轮实践，让我第一次很强烈地意识到：
AI 最有价值的地方，真的不只是“帮我写几段代码”。
如果只把 AI 理解成一个代码补全器，或者一个更强的问答工具，我觉得还是把它看窄了。至少对我来说，这两周它真正帮到我的地方，更多出现在这些环节：
- 在动手之前，先帮我把背景、目标、边界和风险讲清楚
- 在方案不明确时，先帮我把几种实现路径摊开比较
- 在老项目里迭代时，提醒我哪些地方该动，哪些地方最好别动
- 在连续几天推进之后，帮我把结果整理成交接文档和复盘文档
- 在同一类问题重复出现后，帮我把工作方式沉淀成模板、规则和可复用方法
这两周我最大的感受，不是“AI 让我写代码更快了”，而是：
它开始真正进入我完整的工程工作流，参与问题分析、方案制定、结构收口、文档沉淀和后续复用。
这件事对我的触动，其实比“自动生成几段代码”更大。
因为真实项目从来不是一道纯编程题。
很多时候，真正难的部分并不是把功能写出来，而是：
- 先判断问题到底在哪里
- 分清哪些是表现层问题，哪些是业务逻辑问题
- 分清哪些是 Debug 现象，哪些才是真实用户问题
- 在不影响主链路的前提下，把一个需求安全地推进下去
- 让今天做过的判断，明天还能被自己或别人接着用
这些事情，过去往往更多依赖工程师自己的经验和习惯，也更容易停留在脑子里。
而我这两周越来越明显地感受到，AI 可以开始参与这些过程，而且如果用得对，它甚至能把这些原本只存在于脑子里的经验，逐步变成可以复用的外部资产。
比如，一件需求还没开始做之前，我会先把背景、目标、边界和当前代码状态整理清楚，再形成一个实施方案。
一轮改动做完之后，我会补一份结果文档，把做了什么、没做什么、当前版本成立了什么、下一步从哪里接着做写清楚。
当一些协作偏好和工程规则反复出现之后，我会继续把它们沉淀成“记忆文档”或者模板，减少后面重复沟通和重复判断的成本。
以前这些动作我也会做，但更多是零散的、凭经验的，和“系统使用 AI 协作工作”还不是一回事。
而这一次我明显意识到，AI 可以让我把这些流程系统化。
换句话说，它不只是帮我“完成任务”，而是在帮我“建设系统”。
如果一定要概括这个变化，我会觉得过去 1 到 2 年里，我经历了一个很明确的阶段变化：
第一阶段，是把 AI 当成提效工具。
第二阶段，是开始把 AI 纳入自己的工作流，并尝试形成沉淀。
前一个阶段解决的是“这次写代码能不能更快一点”。
后一个阶段关心的是“这套做事方式能不能留下来，能不能复用，能不能继续进化”。
这也是我开始认真记录这件事的真正原因。
也是从这里开始，我第一次认真意识到一件事：
如果我继续只把 AI 当成一个“很好用的开发工具”，那它对我的价值仍然是局部的。
但如果我开始记录它如何进入真实项目交付，开始记录哪些地方真的有帮助、哪些地方只是看起来很强，开始记录哪些方法能留下来、哪些只是一次性技巧，那这件事的意义就不一样了。
它不再只是“我最近又多会了一个工具”，而是开始变成一种工作方式的变化。
我并不想写太多泛泛的 AI 内容。
我对下面这些方向其实没有太大兴趣：
- 追最新热点
- 做脱离场景的工具测评
- 写一堆看起来很厉害、但落不到真实工作里的提示词
- 把所有内容都包装成“效率暴涨”“颠覆一切”这样的结论
这些内容可能有流量，但不是我真正想长期做的东西。
我更想记录的是：
- AI 如何进入真实项目交付
- 老项目迭代时，AI 可以帮工程师做哪些高价值工作
- 什么时候该让 AI 先分析，什么时候该自己先判断
- 怎样把方案文档、交接文档、复盘文档和模板真正用起来
- 哪些方法能沉淀成长期可复用的工作流，哪些只是一次性的技巧
对我来说，这件事的意义不只是“多会一个工具”。
更重要的是，它让我重新思考工程师在 AI 时代的工作方式，也让我第一次很具体地看到自己这两年在使用 AI 这件事上的变化。
我越来越觉得，未来真正有价值的，不只是会不会用某个模型、会不会写某种提示词，而是能不能把 AI 纳入自己的真实工作系统里，让它服务于交付、判断、协作和沉淀。
尤其是在老项目、真实业务、高风险链路这些场景里，这种能力的价值会更明显。
因为这些地方最需要的，不是花哨，而是清楚、克制、可控。
这也是为什么我决定开始系统记录这件事。
接下来，我会主要围绕几个方向持续写下去：
- AI 在真实移动端项目交付中的用法
- 老项目里的低风险迭代和结构收口
- 方案文档、交接文档、复盘文档的写法和价值
- 工程师如何把重复工作沉淀成模板和工作流
- 一些围绕这些方法延伸出来的小实验和小工具
这些内容可能不会很热闹，也不一定特别“抓眼球”。
但我希望它们是实的，是我自己在真实工作里反复验证过的，是过一段时间回头看仍然有价值的。
如果你也在关注类似的问题，比如：
- AI 到底怎样才能真正进入开发流程
- 老项目迭代怎么在不乱动主链路的前提下推进
- 工程经验怎么沉淀成方法，而不是停留在脑子里
那我接下来写的这些内容，应该会和你有一些关系。
我不确定这条记录最终会走到哪里。
但至少从现在开始，我不想再满足于“会用 AI 帮我提效”这一层了。
我更想做的，是把它真正放进工作里，验证它、使用它、记录它，然后慢慢把这些经验沉淀成更长期的东西。
如果你也在做真实项目，也在一边使用 AI、一边重新理解自己的工作方式，欢迎交流。
