AI Coding：从聊天到 Agent 的工作流改造

用 AI 写代码，最容易踩的坑是把它当成一个更聪明的聊天窗口。真正有效的用法，是让 Agent 进入真实项目环境，把每一次任务都变成可以复利的资产。这篇文章记录我整理出来的一套思路，分成四个部分：思维转变、资产沉淀、流程工程化，以及质量闭环。

一、思维的转变——从 chat 到 agent

1. 不要只把 AI 当聊天窗口

Chat 模式适合问答、解释、润色，但不适合复杂项目。复杂任务需要 AI 能读文件、改代码、跑测试、查看结果，而不是只在对话框里给答案。

2. 让 AI 进入真实项目环境

AI coding 的重点是让 Agent 在项目目录里工作。它应该能读取完整上下文，包括代码、文档、配置、测试、历史规则，而不是靠你手动上传几个片段。

3. 目标不是完成一次任务，而是改造工作流

真正的价值不是“这次 AI 帮我写完了”，而是这次任务完成后，下一次类似任务能更快、更稳、更少依赖你。

二、构建可复利的 AI 资产

1. 个人长期资产

把自己长期使用 AI 的经验沉淀下来，比如常用 rules、prompt、skills、MCP、调试方法、代码审查规则、项目模板等。

这些东西可以放在一个专门文件夹里，持续收集和迭代，形成自己的 AI coding 工具箱。

2. 项目上下文资产

每个项目都应该有 AI 能读懂的说明书，比如 AGENTS.md、CLAUDE.md、rules.md、README.md。

里面写清楚项目架构、目录结构、技术栈、测试方法、提交规范、部署流程、常见坑、哪些文件不能乱改等。

3. 任务沉淀资产

每次完成任务后，都要尽量留下可复用的东西，比如测试脚本、共享组件、统一配置、需求文档、实施说明、验收标准、debug 记录。

这些资产会让下一次同类任务不再从零开始。

三、把需求实施流程工程化

1. 先澄清需求，再开始写代码

不要一上来就让 AI 实现。先让 AI 追问需求背景、目标、边界条件、缺失上下文和风险点。需求越清楚，后面越少返工。

2. Document First

把需求写成 PRD.md、change_request.md 或需求说明文档，而不是只放在聊天记录里。

文档里要写清楚：要解决什么问题、为什么做、做什么、不做什么、影响范围、验收标准、测试方法。

3. 大需求先 Plan Mode

如果需求较大或较难，先让 AI 拆计划。让它说明要改哪些模块、分几步做、每一步怎么验证、可能有哪些风险。你先审计划，再让它执行。

4. 让 Agent 调度子任务

对于更大的任务，可以让主 Agent 自己拆分 subagent，比如一个读代码，一个写测试，一个实现，一个 review。你不需要事无巨细地指挥，而是负责把目标和验收标准定义清楚。

四、用测试和反馈闭环保证质量

1. 测试先行

AI coding 最重要的是定义什么叫“完成”。所以在实现前就要写清楚验收标准和测试方式，让 AI 知道如何判断自己做对了。

2. 让 AI 自己跑闭环

理想流程是：AI 修改代码，运行测试，发现失败，读取错误，定位问题，修复，再测试，直到通过。

这比“AI 写一点，人检查一点”的效率高很多。

3. Debug 要改源头

如果 AI 做错了，不要只在对话里反复纠正。要回到源头看：是需求文档不清楚，规则文件缺失，测试没覆盖，还是上下文给错了。

然后修改对应的文档、rules、测试或项目说明。这样这次 debug 也会变成长期资产。

4. 用第二次任务检验是否有复利

第一次用 AI coding 可能不一定特别快。关键看第二次类似需求时，是否能直接复用已有文档、规则、测试和项目结构。

如果第二次还是要重新解释一大堆，说明第一次没有真正沉淀资产。