Appearance
AI Coding 规划与实践
很多人把 AI Coding 理解成一句话：“让 AI 帮我写代码。”
但真正把 AI 用进开发流程之后，你会很快发现，问题根本不在“能不能生成代码”，而在另外几件事上：
- 需求有没有拆清楚
- 上下文有没有给对
- 哪些改动应该让 AI 直接做，哪些必须人工判断
- 改完之后怎么验证、怎么回归、怎么防止越写越乱
所以这页讨论的不是“哪个 AI 编码工具最强”，而是：开发者应该怎样规划 AI Coding，才能让它成为稳定的工程能力，而不是偶尔灵光一现的捷径。
先区分三种不同的事
1. 聊天式问答
你把问题抛给模型，让它解释概念、分析报错、给出思路。这适合拿来补知识、拆需求、写草稿，但通常还没有真正接触代码库状态。
2. 代码生成与编辑
模型直接基于文件内容、上下文和工具调用去改代码。这已经不是普通问答，而是在影响真实代码结构，所以需要更强的约束和验证。
3. Agent 化编码
模型不仅改一段代码，还会自己读文件、搜索、列任务、运行命令、连续多步执行。它的效率可能更高，但风险也更高，因为失控范围更大。
AI Coding 最核心的判断
AI Coding 的质量，通常不取决于模型“聪不聪明”，而取决于你是否把下面四件事做好：
- 任务边界清不清楚
- 上下文是否准确、足够、不过量
- 验证方式是否明确
- 哪些步骤必须人工兜底
如果这四件事没有做好，换再强的模型，也很容易出现“看起来改了很多，实际上越改越乱”的情况。
一条适合开发者的最小工作流
第一步：先拆任务，不要直接让 AI 大包大揽
最危险的用法，是把一个模糊的大任务直接丢给模型，比如“把这个项目重构一下”“把这个模块改好”。这样模型很容易误判范围，改动扩散，最后你也很难 review。
更稳妥的方式是先拆成：
- 目标是什么
- 影响哪些文件
- 哪些只是阅读，哪些会改代码
- 做完以后怎么验收
第二步：只给当前任务真正需要的上下文
上下文过少，模型会瞎猜；上下文过多，模型会抓不住重点。最好的做法不是“把整个仓库都塞进去”，而是先给当前任务需要的文件、规则、接口关系和目标边界。
这也是为什么 AI Coding 和普通 Prompt 工程不同。这里的“上下文工程”不只是措辞，更是任务设计。
第三步：让模型先解释它准备怎么做
如果任务稍微复杂一点，先让模型说明：
- 它理解的目标是什么
- 准备改哪些地方
- 哪些地方存在不确定性
- 验证方式是什么
这一步不是浪费时间，而是在低成本暴露误解。很多偏航，其实在动手前就已经能看出来。
第四步：改完必须验证
AI Coding 最大的问题之一，就是“生成看起来很顺，但没有经过真正验证”。所以你至少要明确：
- 运行什么构建或测试
- 哪些行为需要人工点一下确认
- 有没有可能引入隐藏回归
只看代码 diff 远远不够。
什么任务适合先交给 AI
下面这些任务通常比较适合：
- 补充样板代码
- 改局部文案或结构化字段
- 从已知模式扩展出相似实现
- 先做第一版方案，再由人工 review
- 在明确文件范围内补测试、补注释、补文档
什么任务更容易失控
下面这些任务要格外谨慎：
- 需求本身还没讲清楚
- 涉及多个模块、多个系统、多个角色协作
- 你自己也不确定该怎么设计
- 需要大面积重构，但没有验收标准
- 有安全、权限、支付、数据删除等高风险操作
这类任务不是不能用 AI，而是要先做规划，再让它执行局部步骤。
AI Coding 里最常见的 5 个失控模式
1. 任务太大，模型开始自行扩张范围
它可能顺手重命名、顺手抽象、顺手改样式、顺手改配置，最后已经不是你一开始要的东西。
2. 上下文不完整，模型开始脑补
比如没看到真实类型定义、没读到已有约束、不了解项目规则，就会产出“看起来合理、实际上不匹配”的代码。
3. 只生成，不验证
这是最常见也最危险的问题。模型经常能写出“像是对的”的代码，但真正运行时才会露出边角错误。
4. 把设计决策也外包掉
模型可以帮你比较方案，但如果你自己没有先判断目标和权衡，就很容易把架构决策也一起交出去。
5. 忘了安全边界
当 AI 不只回答问题，而能运行命令、读写文件、调用工具时，风险已经进入系统层面。
写好 AI Coding 提示词的实战技巧
前面讲的工作流和失控模式，本质上都在回答一个问题：怎么把任务交代清楚。落到操作层面，就是你写给 AI 的那段提示词到底长什么样。
AI Coding 场景下的提示词，和普通聊天场景有一个关键区别：你不只是在让模型"回答问题"，而是在让它改真实代码。所以提示词的目标不是"让回答更像样"，而是"让改动可控、可验证、不扩散"。
用结构拆清任务，不要靠一段话说完
模糊的一段话，模型很容易只抓住其中最醒目的部分，其他细节自动忽略。把提示词拆成几个明确的区块，模型的执行准确率会明显提升。
一个在 AI Coding 中比较实用的结构：
text
【角色】你是一个熟悉 React + TypeScript 的前端工程师。
【任务】优化下面这个列表组件的渲染性能。
【输入代码】（粘贴组件代码）
【约束】
- 使用 React.memo 和 useMemo
- 不要改动组件的 props 接口
- 不要拆分成多个文件
【输出要求】只输出修改后的完整组件代码，不需要解释。这个结构不是唯一正确的写法，但它的好处是：任务目标、输入、约束和输出格式都各占一块，模型不容易搞混。
正向描述优先，少用否定句
模型对"应该做什么"的理解，通常比对"不要做什么"更稳定。
原因不复杂：否定句在语义上更间接。你说"不要用 JavaScript"，模型需要先理解 JavaScript 是什么、再理解"不要"、再推断你想要什么。不如直接说"请使用 TypeScript"。
对比两种写法：
- 写法 A：帮我写一份开发计划，文件不要用 txt 格式
- 写法 B：帮我写一份开发计划，输出为 Markdown 格式，注意排版层级清晰
写法 B 直接告诉模型该做什么，模型更容易命中目标。否定句不是不能用，但在描述核心要求时，正向表述通常更稳定。
明确输出边界
AI Coding 场景中，最常见的意外之一是模型"顺手"改了你没让它改的地方。
在提示词里加上输出边界约束，能有效减少这类扩散：
- "只修改
handleSubmit函数，不要改动其他部分" - "只输出代码，不要添加解释"
- "如果不确定某处该怎么改，保持原样并标注 TODO"
这些约束看起来很简单，但在模型执行多步任务时，它们就是在画线。
用多个模型迭代提示词
一个实际可用的提示词，很少是一次写对的。更常见的过程是：写一版、跑一次、看结果、再改。
如果你手边有多个模型可用（ChatGPT、Claude、Gemini、Cursor 内置模型等），可以把这个过程变成一套简单的迭代流程：
第一步：起草
先用任意一个模型把提示词初版写出来。甚至可以让模型帮你起草——"我想让 AI 帮我做 X，请帮我写一段结构化提示词"。初版不用追求完美，能把意图说清楚就行。
第二步：测试
把提示词放到你实际用的工具里跑一次（比如在 Cursor 里用它改代码）。观察输出：格式对不对、有没有遗漏、有没有越界改了不该改的地方。
第三步：针对性修改
根据输出里暴露的问题，调整提示词。常见修改方向：
- 补上模型没注意到的约束
- 删掉让模型分心的冗余信息
- 把模糊的要求改具体
不要盲目把提示词越写越长。每次修改对应一个具体问题，改完再跑一次。
第四步：多模型对比
同一段提示词在不同模型上的表现可能差异很大。一个模型格式完美但逻辑有错，另一个逻辑对了但格式跑偏——比较之后你会更清楚提示词本身哪里还不够稳。
不同模型的能力侧重确实不一样：有的更擅长代码生成，有的推理更强，有的在长上下文场景下更稳定。但具体模型的能力边界变化很快，与其记一张对比表，不如养成"关键任务多跑一个模型对比"的习惯。
第五步：保存和复用
跑通之后，把效果好的提示词保存下来。可以是一个 Markdown 文件，可以是 Cursor 的 rules 文件，也可以是你自己的提示词库。
好的提示词不是用完就扔的。下次遇到类似任务，从模板开始改，比从头写快得多，质量也更稳定。
这套流程不复杂，但它背后有一个判断：提示词的质量不是靠灵感，是靠迭代。写得越多、测得越多、比较得越多，你对"什么样的描述模型容易理解"的感觉就会越来越准。
AI Coding 和站内其他章节的关系
这页不是孤立专题，它和很多章节天然相连：
- Prompt 工程：决定你如何给出任务、约束和目标
- Tool Calling：决定模型如何借助外部能力做事
- Agent 基础原理：决定多步任务为什么会失控
- Prompt Injection 与 AI 安全：决定你怎样看待外部输入与执行风险
- AI 应用系统设计：决定 AI Coding 应该怎样放回完整工程流程
- MCP 协议：决定工具生态如何被标准化接入
一个简单的自查清单
在把一个开发任务交给 AI 之前，你可以先问自己：
- 我是否已经把任务拆到足够小？
- 我是否明确了会影响哪些文件？
- 我是否知道做完之后怎么验证？
- 这件事里是否有必须人工判断的架构或安全问题？
- 如果模型理解错了，我能否很快发现？
如果前 3 条还没想清楚，最好不要急着让 AI 直接执行。
稳定拆任务、控上下文、做验证、守边界——能把这四件事做稳，AI 才会真正融入工程流程。做不稳，就还是偶尔生成几段代码，大部分时间在救火。