AI Coding 经验总结

写在前面

AI 本身只是工具。以大模型为载体，AI 可以进入写作、科研、编程、数据分析和工程管理等不同任务，但学习 AI 并不应与日常工作割裂。更合理的目标是：用 AI 提高解决问题的效率，而不是为了追逐技术名词而学习技术本身。

AI 技术仍处于快速迭代阶段。具体模型、工具和框架会不断变化，真正值得长期积累的是思维方式：如何描述问题，如何组织上下文，如何拆分任务，如何迁移到新架构，如何让模型输出进入可验证的工程闭环。

本文记录的是个人使用 AI Coding 的阶段性经验。它会长期更新，不追求一次性完整，也不一定完全准确，而是持续修正判断、补充案例和沉淀可复用流程。

一句话概括

AI Coding 的核心不是让模型替人写代码，而是把大模型放入一个由上下文、工具、约束、记忆和验证组成的工作系统中，让它在可控范围内持续产生可检查的工程产出。

时间线：从翻译工具到 Agent 工作流

几个关键时间点需要先校准：

回看自己的使用经历，大致经历了四个阶段。

第一阶段是“把 AI 当翻译软件”。硕士阶段第一次接触 GPT-3.5 时，课题组已经经常讨论深度学习、Transformer 和世界模型，但个人使用主要用于英文翻译、润色和概念解释。那时它能给出流畅回答，却经常出现幻觉，信息陈旧，代码也很难直接相信。

第二阶段是“把 AI 当写作和简单编码助手”。GPT-4 发布后，它已经能根据意图修改英文段落，辅助论文表达，也能处理目标明确的简单代码 Bug。但它仍然不适合长难任务，尤其是跨文件重构、复杂状态管理和需要连续验证的任务。

第三阶段是AI Coding 具备可用生产力。Claude 3.5 Sonnet、Claude 4 系列、GPT-5 和 Gemini 3 之后，大模型开始能听懂更自然的需求。对于单文件前端、Matlab 仿真、简单工具脚本和熟悉代码块内的修改，它可以显著节省时间。但这类能力仍然依赖前提：使用者要知道代码大致应该怎么写，能检查模型输出，并能指出错误位置。

第四阶段是Agent 工具把模型能力释放出来。Codex、Claude Code、Cursor 等工具的价值，不只是换了一个更强模型，而是把模型放进了带文件系统、终端、浏览器、规则、记忆和验证机制的工作环境。此时，关键问题变成：如何设计工作流，使模型尽量少犯错，并且在犯错后能被及时发现。

什么是 Agent

ReAct 论文把 Reasoning 和 Acting 结合起来：模型一边推理，一边行动，再根据环境反馈继续推理和行动。这个思想解释了很多现代 Agent 工具的基本形态。

在 AI Coding 场景中，可以把 Agent 理解为：

Agent = LLM + Harness

LLM 是核心驱动，负责理解意图、生成方案、编写代码和解释结果。Harness 则是围绕模型的一整套工程外设，包括规则、权限、工具、记忆、反馈回路和验证机制。

如果只看模型本身，它仍然只是一个生成式系统。它会预测下一个合理输出，但合理不等于正确。Harness 的价值就在于让模型进入可控环境。

我更愿意把 Harness 的核心作用概括为三件事：

这三件事构成闭环。Inform 让模型有方向，Constrain 降低破坏性，Verify 让结果可检查。没有这个闭环，AI Coding 很容易退化为模型写一段代码，人再慢慢排雷。

传统 AI Coding 与 Agent 的差别

传统 AI Coding 的模式是：

用户描述需求 -> 大模型生成代码 -> 人工复制运行 -> 人工 Debug -> 再问模型

这种方式适合小任务，虽然准确率较高，因为人始终在最低层循环里检查每一段代码。但它的缺点也明显：上下文容易丢失，模型不知道项目全貌，调试过程依赖人工搬运错误信息。

Agent 模式的变化在于，它把一部分低层循环交给工具系统：

用户描述目标 -> Agent 理解任务 -> 读取项目 -> 修改文件 -> 调用工具 -> 验证结果 -> 失败后继续修正

这并不意味着人可以完全退出。更合理的位置是从逐行盯代码转向管理工作流。

人负责确定目标、设定边界、审阅关键逻辑、判断结果是否满足真实需求。Agent 负责执行重复性的读取、修改、运行和修正。

因此，AI Coding 的能力上限不只取决于模型参数，也取决于项目是否具备清晰的 Harness：是否有规则，是否有文档，是否有测试，是否有可运行环境，是否有明确的验收标准。

从 0 开发：优先使用 TDD

如果是从 0 开发，建议使用 TDD，即 Test-Driven Development。这里的重点不是教条式测试覆盖率，而是先把需求变成可执行反馈。

推荐流程如下：

1. 先写 Specification 文档。
   文档要说明项目目标、核心功能、技术路线、输入输出、约束条件和验收标准。

2. 写测试用例。
   当前还没有实现代码，因此测试必定失败。这个失败是合理的，因为还没有写项目的代码。

3. 再按模块开发。
   不要一次性让模型生成整个项目。越大的任务，越容易出现幻觉、遗漏和结构混乱。

4. 每完成一个模块就运行测试。
   让失败信息成为模型下一轮修改的输入，而不是让模型凭空猜测哪里错了。

5. 最后做人工审阅。
   TDD 不能保证完全正确，它只能把一部分主观判断转化为可执行反馈。关键逻辑、边界条件、权限操作和数据一致性仍然需要人工检查。

这里要特别注意顺序：不要先让模型写完整功能，再让它补测试。这样很容易出现为了让测试通过而写测试的情况，测试看起来完整，但没有真正约束行为。

重构旧项目：先让模型理解边界

重构老项目时，项目体量越大，越不能直接要求模型整体重构。因为旧项目通常存在隐含依赖、历史兼容逻辑和非显式接口，大模型很容易改对局部、破坏整体。

更稳妥的方式是先建立项目文档：

• 这个项目解决什么问题。

• 每个文件或模块负责什么功能。

• 模块之间的接口是什么。

• 当前有哪些已知问题。

• 哪些行为不能改变。

• 编码风格和目录组织有什么约束。

小体量项目可以一个模块一个模块替换。大体量项目更适合局部重构：先选一个边界清楚、测试容易验证、影响范围可控的模块。完成后再扩展到下一个模块。

我自己的经验是，AI 重构最容易出问题的地方不是语法，而是看似合理的兜底逻辑。模型为了让代码跑通，会主动添加 fallback、默认值、宽松异常捕获或冗余分支。这些代码短期减少报错，长期会掩盖问题。因此，重构任务必须明确禁止不必要的 fallback，并要求模型解释每个异常处理的必要性。

常见风险

AI Coding 最常见的风险不是完全不会写，而是写得像对的，这可能影响更大，因为很难debug。

第一类风险是幻觉。模型可能引用不存在的 API、过时的库版本或不适合当前框架的写法。解决方法是让 Agent 查官方文档、读取本地依赖、运行最小验证。

第二类风险是顺从。模型会倾向于满足用户表达，即使用户的假设是错的。对于时间线、版本号、论文信息、框架能力等事实性内容，必须联网核验或查官方来源。

第三类风险是过度设计。模型容易引入多余抽象、无关依赖和复杂配置。处理方式是把任务限定在当前需求，不做无关重构。

第四类风险是测试作假。模型可能写出只验证表面行为的测试。比较稳妥的方式是先写测试，再写实现；必要时加入隐藏用例、边界条件和人工审阅。

第五类风险是上下文污染。长对话中规则会被稀释，模型可能忘记早期约束。因此，长期项目需要把稳定规则写入 AGENTS.md、README、SPEC 或技能文件，而不是只依赖聊天记录。

当前可复用工作流

目前我认为较稳妥的 AI Coding 流程如下：

明确目标
-> 写 Specification
-> 写规则和边界
-> 让 Agent 阅读项目
-> 先写测试或验收标准
-> 小步实现
-> 运行验证
-> 人工审阅关键逻辑
-> 把稳定经验写回项目规则

这个流程的核心不是让步骤变复杂，而是让模型每一步都有依据。任务越清晰，模型越不容易偏离；验证越具体，模型越容易自我修正。