什么是 AI 编程工作流？
AI 编程工作流是一种在整个软件任务中使用 AI、同时又不放弃工程判断的可重复方法。开发者定义成功的标准，并审查每一项重要改动。编程 agent 首先调查项目并提出方案，获得批准后，才能编辑相关文件并运行项目的检查。
为什么无结构的 AI 编程反而会增加工作量
无结构的 AI 编程之所以让人觉得快，是因为代码会立即生成出来。隐藏的代价会在之后显现出来——当开发者必须理清各种假设，或修复那些超出原始需求范围的改动时。
规划与执行同时发生
当需求含糊不清时，agent 必须在已经开始编写代码的同时，自行决定该功能应该如何运作。这些决策可能与开发者的初衷不符。例如，如果你说“添加一个深色模式切换按钮”，agent 并不知道该按钮应放在界面的哪个位置，也不知道用户关闭应用后是否应记住这一选择。
过于宽泛的提示词会产生难以评审的改动
范围宽泛的需求会促使 agent 在一次改动中修改项目中多个相互关联的部分。生成的补丁可能过大，即使其中每个文件单独看起来都合理，开发者也难以有信心理解整体改动。例如，“构建一个设置页面”可能同时影响界面本身，以及偏好设置的存储方式。
缺乏上下文会导致生成通用化的代码
编程 agent 无法遵循它从未见过的项目约定。如果没有相关文件或仓库说明，它可能会在已有抽象的情况下重复引入一个新的抽象，也可能使用与已安装依赖版本不匹配的 API。
生成速度快掩盖了返工的成本
生成时间并不等于交付时间。一分钟内生成的补丁，仍可能需要一个下午的时间来调试。更准确的衡量标准，是从明确的需求到团队愿意维护的、经过验证的改动之间所花费的时间。
AI 编程工作流一览
下面的工作流让开发者掌控决策，同时将可重复的调查和实现工作交给 agent 完成。
| 阶段 | 人类职责 | AI 职责 | 产出 |
|---|---|---|---|
| 定义 | 设定目标和约束条件 | 识别歧义点 | 已确认的需求规格 |
| 探索 | 确认范围 | 检查相关文件和依赖项 | 上下文地图 |
| 规划 | 确认架构与权衡取舍 | 制定有序的任务计划 | 已审阅的计划 |
| 实现 | 把控范围 | 进行针对性的代码修改 | 可审阅的差异 |
| 验证 | 定义预期行为 | 运行测试并检查失败情况 | 测试证据 |
| 评审 | 做出最终判断 | 暴露风险和不一致之处 | 已批准的改动 |
| 上线 | 授权集成 | 总结工作内容和剩余风险 | 带有发布证据的已审阅改动 |
Kimi Code 可以通过检查仓库文件、进行已批准的编辑，以及执行项目的验证命令来支持这一循环。
第一步：先定义结果，再要求生成代码
在规定具体实现方式之前，先描述期望的行为。明确受影响的用户或系统，界定任务边界，并添加改动完成后可用于检查的验收标准。
来看一个简单的例子。假设你想为现有的 Web 应用添加深色模式，你可以向编程 agent 提出这样的需求：
agent 可以据此行动，但它必须自行补全缺失的需求。它可能把切换按钮放在界面中错误的位置，或只在某一页面应用深色模式。生成的代码在技术上或许可以运行，但仍可能交付出不符合预期的用户体验。
更有用的提示词会在 agent 开始编辑之前先定义好结果：
这个版本为 agent 设定了明确的目标，防止它擅自做出产品层面的决策。同时，它也为开发者提供了具体的方式来评审完成的工作。你不必再判断这个功能“看起来是否完成”，而是可以对照所述需求来检查其实际行为。
第二步：选择合适的编程执行环境和模型
模型决定了 AI 理解和推理代码的能力高低，而编程执行环境则决定了这种推理能否在你的项目中转化为经过验证的改动。提前选定这两者，能避免你围绕无法胜任任务的工具搭建工作流。
选择能够完成整个循环的执行环境
有用的编程执行环境不应仅停留在生成代码片段的层面。它需要能够访问仓库、拥有编辑文件的权限，并能运行项目现有的命令。当任务涉及多个文件时，规划支持和明确的审批机制同样重要。
让模型匹配任务需求
简单的快速修改可能只需要一个速度快的编程模型。复杂的调试或跨文件重构则需要更强的推理能力，以及足够的上下文来理解周边代码。该模型还应该能够可靠地使用运行环境所暴露的工具。
在 Kimi Code 中使用 Kimi 编程
Kimi Code 为任务级开发提供了完整的运行环境。它可以探索陌生的代码仓库，在编辑前先制定计划，更新相关文件，并在真实项目上运行测试。你可以在终端、浏览器或兼容的 IDE 中使用它。
对于第三方编程工具，Kimi Code 平台提供了稳定的模型 Kimi K3。该模型可以在不改动客户端配置的情况下进行升级。当迭代速度更重要时，高速版模型可以在保持相同编程能力的同时提供更高的输出速度。
Kimi Code 与 Kimi 模型共同覆盖了工作流的两端：模型负责代码推理，运行环境则将这些推理转化为可供审查的变更。
第 3 步：让编程 agent 检查项目
在明确目标之后，让 agent 定位控制当前行为的代码。探索工作应先于任何文件修改，用以缩小任务范围。
先从代码仓库自身的说明开始
先向 agent 展示代码仓库自身的说明。这些内容可能位于 README.md、CONTRIBUTING.md 或某个 agent 指令文件中。其中有用的信息包括项目实际使用的命令、代码规范，以及不可执行的操作。
可以使用如下提示词：
响应中应指明它读取了哪些指令文件，并引用相关命令。如果它提出的命令并未出现在代码仓库中，先确认该命令的来源，然后再运行它。
在修改代码之前先找到相关代码
有用的上下文地图会指出具体文件，并说明每个文件的重要性所在。仅列出大致的目录是不够的。如果响应遗漏了你知道涉及其中的共享工具模块，应在开始规划前修正这份地图。agent 应该从入口点开始，追踪该行为一直到它所依赖的各个模块。它还应找到现有的测试，以及可参考的类似实现（如果存在）。
仅在必要时引入外部上下文
当代码库无法回答某个问题时，再引入外部文档。提供准确的官方文档链接，或让 agent 自行查找官方来源。文档版本应与代码仓库中安装的版本一致。错误日志和问题描述也很有用，但在放入提示词之前，需先移除凭证或私人用户数据。
在允许任何修改之前，先检查工作树并记录已有的改动。完整的版本控制流程将在第 8 步中介绍。
第 4 步：将规划与执行分开
规划和编码在审查时需要回答不同的问题。在规划阶段，你要判断提出的方向是否符合系统架构。在实现阶段，你要检查是否正确执行了已批准的方向。
使用一个明确要求不写代码的规划提示词：
在批准计划之前先进行审查。确认它在适当情况下使用了项目中已有的抽象。留意隐藏的范围扩大问题，尤其是需求之外新增的依赖或公开 API 变更。检查提出的测试是否确实验证了所需的行为，而不仅仅是运行了新写的函数。
此阶段的输出结果是一份已获批准的计划。仅仅因为 agent 给出了一份详尽的响应，并不意味着任务已经“完成”。你需要自己修改计划，或要求修订，直到假设条件和文件范围都准确无误为止。
第 5 步：把计划拆分为可审查的任务
每个实现任务应有一个明确的目标，以及一种验证结果的方式。这样可以让改动足够小，便于审查，也更容易在出问题时找到原因。
例如，第 1 步中的深色模式功能可以拆分为以下任务：
检查现有的颜色变量和与主题相关的样式。
添加主题偏好设置，并保存用户的选择。
将深色主题应用到共享布局和组件中。
在设置菜单中添加主题切换开关。
为切换和保存所选主题添加测试。
检查主要页面是否存在视觉或无障碍访问方面的问题。
按顺序逐一完成这些任务，而不要让 agent 一次性实现整个功能。对于单个实现任务，可以使用类似这样的提示词：
预期结果是一次范围聚焦的代码改动，并附带实际运行过的测试。在进入下一个任务之前，先对两者都进行审查。如果 agent 同时添加了设置开关或修改了不相关的组件，先把这些改动分离出来或撤销。
当 agent 反复难以完成某个任务时，把这个任务拆得更小。例如，先只让它添加主题偏好设置，之后再实现持久化。更细粒度的任务可以减少 agent 需要做出的假设数量，也能让你在继续之前有更清晰的验证节点。
第 6 步：在紧凑的循环中实现、测试并检查
计划拆分为可管理的任务之后，逐一完成它们。在改动的目的和范围还清晰可辨时及时进行审查。
对每个任务使用以下循环：
先审查差异。确认 agent 只改动了当前任务所需的文件。如果补丁中包含无关的重构，或是计划在后续步骤中完成的工作，先移除或分离这些改动，然后再运行测试。
接下来，使用代码仓库中已定义好的验证命令。通常可以在 package.json、项目文档或 CI 配置中找到这些命令。例如，一个使用 npm 脚本的 JavaScript 或 TypeScript 项目，可能会提供如下命令：
先运行聚焦的单项测试，以获得更快的反馈。如果通过，再继续进行更全面的检查。成功的运行结果应不出现任何错误：
以上命令仅为示例。请勿在未确认项目实际使用的包管理器和脚本前，将其直接复制到仓库中使用。Python 或 Go 项目的验证流程会有所不同，甚至两个 JavaScript 项目使用的脚本名称也可能不一样。
小贴士：用 Kimi Code 落地这套工作流
Kimi Code 是在任务层面工作，而不仅仅是逐行补全。描述你想要的结果，它就能找到相关代码，提出实现方案，更新必要的文件，并运行项目的检查。你收到的是一处聚焦的改动，可以直接审阅，而不必自己拼接每一个步骤。
更快理解陌生代码库
Kimi Code 可以从一个入口点开始，沿执行流程追踪相关模块。它能识别相关测试和项目中已有的模式，减少你手动收集文件或解释仓库运作方式所花的时间。
把代码之外的信息也带入任务
开发场景中常常涉及错误截图、设计参考、图表或录屏。Kimi Code 可以在处理源代码的同时使用这些多模态输入，让实现结果更贴合最初定义任务的那些依据。
在真实项目中测试改动
Kimi Code 可以在编辑完成后运行仓库中已有的测试和质量检查命令。如果检查失败，它会读取实际的报错输出，并据此继续调整，这比一份从未真正运行过的孤立代码建议更让人放心。
把好用的工作流变成可重复的流程
Skills 可以为重复出现的任务保存操作说明，Hooks 可以在关键节点触发预设的动作。MCP 让 Kimi Code 连接到团队已经在用的工具，而 Plugins 则可以把这些能力打包成一套更易复用、便于分享的配置。
让长任务持续推进
对于无法在一次短会话中完成的工作，/goal 可以为 Kimi Code 设定明确的目标和完成标准，供其推进。它会在多轮会话中跟踪进度，让任务持续推进，而不需要你每次都重新说明完整目标。
第 7 步：以维护者的视角审查 AI 生成的代码
在接受这处改动之前，自己先读一遍最终的 diff。检查代码是否按要求正常工作，以及是否契合现有项目。
正确性
代码是否满足验收标准？检查正常的用户流程以及至少一种错误情况。确保测试覆盖了你所要求的行为。
架构
代码是否遵循了项目中已有的模式？逻辑应放在合适的模块中，避免不必要的抽象。
安全性
检查新的输入是否经过校验，权限是否得到落实。确保日志不会泄露密钥或个人数据。接受任何新依赖之前先进行审查。
可维护性
代码本身应该易于理解，不必依赖智能体的解释。命名应清晰，注释只应解释那些从代码本身不易看出的决策。
范围
确认 diff 中只包含当前任务所需的改动。移除无关的重构、意外的接口变更以及不必要的格式调整。
智能体生成的摘要可以辅助审查，但不能替代阅读代码本身。不要交付你自己无法解释的代码。
第 8 步：在整个工作流中使用版本控制
版本控制能让 AI 辅助完成的工作更易于检查和恢复。虽然这里把它列为一个独立步骤，但其保护作用在智能体编辑任何文件之前就已经开始。一开始就检查工作区状态，这样才能把已有的工作和任务过程中产生的改动区分开。
在仓库根目录打开终端并运行以下命令：
git status --short
git diff --stat
git diff一个干净的初始工作区，运行 git status --short 应该没有任何输出。如果已经有文件被修改过，记录下来并告知智能体不要覆盖它们。每完成一个任务后，再次检查 diff。是否将已验证的状态提交为版本控制检查点，应由开发者自行决定。
当一次实验可能涉及很多文件时，使用单独的分支或 worktree。多个智能体并行工作时不应编辑同一个工作目录。给每条工作线明确的文件归属，等其检查通过后再进行整合。
不要允许编程 agent 在未经明确批准的情况下重写历史、丢弃本地工作、强制推送或发布改动。这些操作的影响范围远大于普通的文件编辑，需要单独作出决定。
第 9 步：在多次编码会话之间保留上下文
长期任务往往会跨越多次对话。请把工程状态保存在仓库中的相关产物里，而不是依赖聊天记录。
维护一份简短的功能文档，包含：
已确认的规格说明
已批准的实现方案
已完成的任务以及当前的待办事项
改变了原方案的各项决策
已经运行过的命令及其最新结果
已知风险或待解决的问题
用交接提示词开启新会话：
回复内容应与文档以及当前仓库状态保持一致。在让新会话继续之前，先解决任何不一致之处。这样的交接能减少 AI 编程 agent 从不完整的对话历史中重建项目状态的需要。
多 agent AI 编程工作流如何运作
多 agent AI 编程工作流会为不同的 agent 分配不同的角色。一个 agent 可以负责调查仓库，另一个则负责审查已完成的 diff。其价值来自职责的划分，而不是同时打开多个对话窗口。
一个实用的配置可以包含以下角色：
规划者： 将需求映射到代码库，并提出一个有序的计划，但不直接编辑文件。
实现者： 在一个隔离的工作区中完成范围明确的任务。
测试者： 检查验收标准，并独立复现故障。
审查者： 检查 diff 是否正确、是否存在隐藏风险，而不是假定实现一定是对的。
人工整合者： 批准决策、控制合并顺序，并核实整合后的结果。
当任务能够清晰拆分时，多 agent 工作流的效果最好。为每个 agent 提供同一份已批准的规格说明，明确各自的职责归属，并使用隔离的分支或工作树来避免冲突。对于小修复或依赖单一变更文件的任务，通常单个 agent 效率更高。
Kimi Code 可以将较大的任务拆分给多个具有独立上下文的子 agent。借助 Agent Swarm，多个子 agent 可以并行处理任务的不同部分，再将各自的结果汇总回主工作流以供审查和整合。这样可以缩短执行时间，同时任务边界和最终批准仍由你掌控。
根据任务选择合适的工作流
并非所有编程任务都需要同等程度的规划。简单的修复可以快速推进，而复杂或风险较高的变更在发布前需要更多审查。
小改动： 检查相关代码，进行一次有针对性的编辑，运行相关测试，并审查 diff。
中等功能： 编写一份简短的规格说明，批准实现方案，并将工作拆分为若干较小的任务完成。在审查前运行更广泛的测试套件。
高风险变更： 增加设计评审和回滚方案。涉及身份验证、支付或数据迁移的变更，还可能需要安全评审和分阶段发布。
多 agent 项目： 为每个 agent 提供同一份规格说明，并明确各自的任务归属。合并各方成果后，再次运行相关的完整测试集。
Kimi Code 可以支持上述每一种工作流。对简单任务采用轻量流程，而当变更更难以撤销或更可能影响用户时，再加入更多规划和审查环节。
可复用的 AI 编程工作流提示词
可将此模板用于任何编程 agent。将各占位字段替换后再提交给该 agent。
你可以将其作为 Kimi Code 中的开场指令。随着工作的推进，逐步更新 Current phase 和 Task，而不是用一个提示词涵盖整个功能。
结语
可靠的 AI 编程工作流的目标不是让生成的代码越多越好，而是尽早暴露错误的假设，并保持每一次变更都可审查。Kimi Code 通过读取和编辑代码、执行 shell 命令、获取相关网页内容，并随任务推进调整其行为，来支持这一流程。架构设计和最终发布决策仍由开发者负责。从一个小而可验证的任务开始，只有在项目风险确实需要时，才增加更多流程。
常见问题
kimi、kimi web 和 kimi acp。