系列目录
1. 从一次不成熟的尝试开始
我第一次比较认真地接触 AI 编程，是在大一之前的暑假。那时候的 AI 远没有今天这样稳定，幻觉问题很明显，开源社区对它参与开发也普遍保持谨慎。我刚接触 C++，遇到问题时经常去问豆包和 Kimi。现在回头看，很多回答即使写得很完整，我也没有足够的经验判断它到底对不对。
这种使用方式持续了一个学期：我把 AI 当作一个问答工具，问接口、问语法、问报错原因。它偶尔能帮我解决问题，也经常给出看似合理但并不可靠的答案。那时我对 AI Coding 的理解还很简单，基本等同于“把问题描述清楚，然后等它给我一段代码”。
真正改变我看法的是后来进入学校实验室之后。寒假期间，实验室安排了一个训练模型的任务，形式上类似手写数字识别。因为经验不足，我几乎是从配置环境开始学起。那次我还记得很清楚：在等待 PyTorch 下载的时候，我刷到了 Claude Code。它不是我第一次看到相关讨论，却是最早让我真正意识到 Coding Agent 形态的工具之一。
当时我还无法直接使用 Anthropic 的 API，最后接入的是 Kimi API。即便模型能力和接入条件都不算理想，Claude Code 展现出来的工作方式仍然让我感到明显不同：它不是只回答某个函数怎么写，而是会围绕项目文件、命令执行、错误信息和修改结果形成一个连续过程。
我把这个过程展示给同一个实验室的朋友看时，我们关注的重点也发生了变化。大家不再只是讨论某个接口叫什么、某段代码怎么补全，而是开始讨论模型接入成本与可用性、上下文如何组织、工具执行是否可靠，以及怎样让 AI 真正参与一个开发任务。也就是从那时开始，我对 AI Coding 的理解逐渐从“问答工具”转向“工程协作流程”。
2. AI Coding 不等于自动编程
我并不认为 AI Coding 的目标是让 AI 自动完成整个项目。真实开发里，一个项目能否成立，取决于需求边界、技术选型、代码结构、测试策略、上线约束和长期维护成本。这些问题不能简单交给模型判断。
更准确地说，AI Coding 是一种工程辅助能力。它可以参与需求拆解，帮助理解陌生代码，完成局部实现，定位报错，辅助重构，也可以把调试过程和文档整理得更清楚。它确实能提高效率，但这个效率来自开发流程被重新组织，而不是开发者退出判断。
最危险的情况并不是 AI 不会写代码，而是它写出的代码看起来正确。语法合理、命名自然、逻辑也似乎连贯，但没有经过测试，没有放回真实项目运行，也没有检查边界条件。这类代码很容易通过第一眼审查，却在后续集成时暴露问题。
因此，我更愿意把 AI 生成代码看作中间环节。它不是工作的终点，而是进入验证流程之前的一次候选修改。真正决定代码是否可靠的，仍然是测试、运行、回归检查、代码审查，以及开发者对项目约束的理解。
3. 真正困难的是上下文与约束
很多人第一次使用 AI Coding 时，会把重点放在 prompt 上。prompt 当然重要，但单次 prompt 很容易失效。它通常只能表达当前问题，却很难稳定保存项目的长期约束。
真实项目里的 AI 需要知道更多东西：项目结构是什么，技术栈是什么，代码风格如何，依赖如何安装，服务如何启动，测试如何运行，哪些文件不能动，哪些历史实现不能轻易改。这些信息如果每次都临时补充，成本会很高，也很容易遗漏。
所以我开始更关注上下文管理。Prompt 更像临时指令，适合描述这一次要做什么；Spec 或 SDD 更像稳定约束，用来说明需求边界、验收标准和设计取舍。项目文档、AGENTS.md、memory、llm-wiki、skills、hooks 等机制，本质上都不是为了堆工具名，而是在解决同一个问题：怎样让 AI 在当前项目里知道“应该怎么写”。
这也是我认为 AI Coding 和普通问答最大的区别。AI 并不总是不知道怎么写代码，它更经常是不知道在这个项目里应该怎么写。没有上下文，它会按通用经验生成答案；有了上下文，它才可能进入项目的工程约束。
4. 这个系列会讨论什么
这个系列不会写成工具推荐合集，也不会只记录某个软件的使用步骤。我更想整理的是一套能长期复用的工作流理解：如何把 AI 放进需求表达、上下文准备、代码修改和结果验证这些环节里。
后续我会先讨论 Spec / SDD，重点是如何从一句 prompt 过渡到更稳定的需求约束。临时指令可以推动一次对话，但项目级任务需要更明确的边界、目标和验收条件。
接着会讨论 Context 管理。一个真实项目不是几段孤立代码，AI 需要理解目录结构、运行方式、测试入口和已有约定。上下文不是越多越好，而是要足够准确、可维护，并且能在任务中持续发挥作用。
工具链也会是这个系列的一部分。我会结合 superpowers、everything、GSD、OMO、Ralph Loop、hooks、clean-code 等工具或机制，分析它们分别解决什么问题：有的偏规划，有的偏执行，有的偏反馈，有的偏约束。但重点仍然是工具背后的分工，而不是某个工具本身。
质量控制会单独展开。AI Coding 如果只停留在生成代码，很容易把风险推迟到集成阶段。TDD、单元测试、端到端验证、静态检查和回归测试，都是把模型输出纳入工程流程的方式。用测试约束生成代码，比单纯相信模型输出更可靠。
我也会记录多 Agent 协作的实践。规划、实现、审查、测试这些角色在传统开发中本来就存在，Coding Agent 只是提供了一种新的组织方式。关键是任务边界要清楚，结果要能被检查，多个 Agent 之间不能只是在并行地产生更多不可验证的修改。
最后，我会整理一些个人实践原则：如何避免失控修改，如何控制重构范围，如何减少上下文误解，如何拒绝看起来完整但无法验证的代码。这些原则共同指向一个目标：形成稳定、可控、可验证的 AI Coding 工作流。
5. 我希望形成的工作流理解
我写这个系列，不是为了证明某个工具最强。工具会变化，模型会变化，接口也会变化。今天好用的接入方式，过一段时间可能就会被新的产品形态替代。
但工程中的基本问题不会消失：需求是否明确，上下文是否充分，修改是否可控，结果是否可验证。只要这些问题还存在，AI Coding 的价值就不应该只被理解为“更快生成代码”。
真正值得记录的，是 AI 如何进入这些工程环节。它怎样帮助我们表达需求，怎样读取和维护上下文，怎样完成局部修改，怎样接受测试和审查的约束。开发者仍然需要负责判断、取舍和验证，只是工作流中的一部分劳动可以被重新分配。
这也是 AI Coding 这个系列想讨论的核心：AI Coding 不是自动编程，而是一次开发流程的重新组织。