什么是 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 for Coding 使用
Kimi Code 为任务级开发提供完整的工具支持。它可以探索陌生的仓库、在编辑前制定计划、更新相关文件，并针对真实项目运行测试。你可以在终端、浏览器或兼容的 IDE 中使用它。
对于第三方编程工具，Kimi Code 平台提供稳定模型 Kimi K3。该模型可以升级，无需你更改客户端配置。当迭代速度更重要时，highspeeed 模型可提供相同的编程能力，同时输出速度更快。
Kimi Code 与 Kimi 模型共同覆盖工作流的两个方面：模型负责代码推理，工具则将这些推理转化为可供审查的改动。
第 3 步：让编程 agent 检查项目
在明确目标之后，让 agent 定位控制当前行为的代码。在修改任何文件之前，应先通过探索缩小任务范围。
先查看仓库自身的说明
先向 agent 展示仓库自身的说明。这些说明可能位于 README.md、CONTRIBUTING.md 或 agent 指令文件等文件中。有用的信息包括项目实际使用的命令、代码约定，以及不允许执行的操作。
可以使用如下提示词：
响应内容应指出它读取了哪些指令文件，并引用相关命令。如果它提出的命令在仓库中并未出现，在运行之前先询问该命令的来源。
在修改代码前先找到相关代码
有用的上下文地图应指出具体文件，并说明每个文件的重要性。仅列出宽泛的目录是不够的。如果响应遗漏了你知道涉及其中的共享工具函数，应在开始规划前先纠正这份地图。agent 应从入口点追溯行为，直到其依赖的模块。它还应找到已有的测试，以及可参考的类似实现（如果存在）。
仅在需要时引入外部上下文
当代码库无法回答某个问题时，再引入外部文档。提供确切的官方文档 URL，或让 agent 自行定位官方来源。确保文档版本与仓库中安装的版本一致。错误日志和 issue 描述也很有用，但在放入提示词之前，需先移除其中的凭据或用户隐私数据。
在允许任何修改之前，检查工作区并记录已有的改动。完整的版本控制流程将在第 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 可以在完成编辑后运行仓库现有的测试和质量检查命令。如果某项检查失败，它会读取实际的错误输出，并据此继续调整，这比一个从未被执行过的孤立代码建议更可靠。
把好的工作流沉淀为可复用的流程
技能可以保留重复性任务的操作说明，Hooks 则会在关键节点触发预设动作。MCP 能把 Kimi Code 和团队已在使用的工具连接起来，Plugins 可以把这些能力打包成一套更易复用、易分享的配置。
让较长的任务持续推进
对于无法在一次短会话中完成的工作，/goal 会为 Kimi Code 设定明确的目标和完成标准。它会在多轮对话中持续跟踪进度，让任务能够继续推进，而不需要你每次都重新说明完整目标。
第 7 步：以维护者��身份审查 AI 生成的代码
在接受改动之前，自己先阅读最终的 diff。检查代码是否按要求工作，是否与现有项目相符。
正确性
代码是否满足验收标准？检查正常的用户流程，以及至少一种错误情况。确认测试覆盖了你所要求的行为。
架构
代码是否遵循了项目中已有的模式？逻辑应放在恰当的模块中，避免不必要的抽象。
安全性
检查新的输入是否经过验证，权限是否得到执行。确保日志不会泄露密钥或个人数据。在接受任何新依赖之前先进行审查。
可维护性
代码本身应当是可理解的，不必依赖 agent 的解释。命名要清晰，注释只需说明那些从代码本身看不出来的决策。
范围
确认 diff 中只包含当前任务所需的改动。移除无关的重构、意外的接口变更以及不必要的格式调整。
agent 生成的摘要有助于审查，但不能替代阅读代码本身。永远不要上线一段你无法解释的代码。
第 8 步：在整个工作流中使用版本控制
版本控制让 AI 辅助完成的工作更易于检查和恢复。虽然这里将它列为独立的一步，但其保护作用其实在 agent 修改任何文件之前就已开始。在任务开始时先检查工作区，这样才能区分已有的工作和任务过程中产生的改动。
在仓库根目录打开的终端中运行以下命令：
git status --short
git diff --stat
git diff一个干净的初始工作区应该在运行 git status --short 时没有任何输出。如果已有文件被修改，先记录下来，并告知 agent 不要覆盖这些文件。每完成一项任务后，再次检查 diff。开发者应自行判断经过验证的状态是否可以作为一个版本控制检查点。
当一项实验可能涉及大量文件时，使用单独的分支或 worktree。并行运行的多个 agent 不应编辑同一个工作目录。给每条工作线明确的文件归属，只有在其检查通过之后再进行整合。
不要在没有明确批准的情况下，让编程 agent 改写历史、丢弃本地工作、强制推送或发布改动。这些操作的影响范围比普通的文件编辑大得多，需要单独决策。
第 9 步：在多个编码会话之间保留上下文
长时间的任务往往会跨越多次会话。应把工程状态保存在仓库中的产出文件里，而不是依赖聊天记录。
保留一份简短的功能文档，包含：
已确定的规格说明
已批准的实现方案
已完成的任务以及当前的待办事项
改变原方案的决策
已执行的命令及其最新结果
已知风险或待解决的问题
用交接提示词开启新会话：
回复内容应与文档以及当前仓库状态保持一致。在让新会话继续之前，先解决任何不一致之处。这样的交接可以减少 AI 编程 agent 从不完整的对话历史中重建项目状态的需要。
多智能体 AI 编程工作流如何运作
多智能体 AI 编程工作流为不同的智能体分配不同的角色：一个智能体负责调查仓库，另一个负责审查已完成的差异。其价值来自职责划分，而不是同时打开多个对话窗口。
一套实用的配置可以包含以下角色：
规划者： 将需求映射到代码库，提出有序的计划，但不编辑文件。
实现者： 在隔离的工作区中完成范围明确的任务。
测试者： 检查验收标准，独立复现失败情况。
审查者： 检查差异是否正确、是否存在隐藏风险，而不预设实现一定正确。
人工整合者： 批准决策，掌控合并顺序，并验证合并后的结果。
当任务能够清晰拆分时，多智能体工作流的效果最好。为每个智能体提供相同的已批准规范，明确任务归属，并使用隔离的分支或工作树来避免冲突。对于小修复或依赖单一变更文件的任务，通常单个智能体更高效。
Kimi Code 可以将较大的任务拆分给多个子 agent，各自拥有独立的上下文。借助 Agent 集群，多个子 agent 可以并行处理任务的不同部分，再将结果反馈给主工作流进行审查和整合。这样可以缩短执行时间，同时任务边界和最终批准权仍由你掌控。
根据任务选择工作流
并非每项编程任务都需要同等程度的规划。简单的修复可以快速推进，而复杂或有风险的变更在发布前需要更多审查。
小改动： 检查相关代码，做一次聚焦的修改，运行相关测试，并审查差异。
中等功能： �写简短的规范，批准实现方案，并将工作拆分成若干较小的任务完成。审查前运行更广泛的测试套件。
高风险变更： 增加设计评审和回滚方案。涉及身份验证、支付或数据迁移的变更还可能需要安全评审和分阶段发布。
多智能体项目： 为每个智能体提供相同的规范，并明确任务归属。合并各方工作后，再次运行全套相关测试。
Kimi Code 可以支持上述每一种工作流。对简单任务使用轻量流程，当变更更难撤销或更可能影响用户时，再增加规划和审查环节。
可复用的 AI 编程工作流提示词
将此模板用于任何编程 agent。替换每个方括号字段后提交给 agent。
你可以将此作为 Kimi Code 中的开场指令。随着工作推进更新 Current phase 和 Task，而不是用一条提示词覆盖整个功能。
结语
可靠的 AI 编程工作流并不以生成最多代码为目标，而是尽早暴露错误的假设，并让每次变更都可审查。Kimi Code 通过读取和编辑代码、执行 shell 命令、获取相关网页内容，并根据任务进展调整其行为来支持这一流程。架构和最终发布决策的责任仍在开发者身上。从一个小而可验证的任务开始，只在项目风险确实需要时增加流程。
常见问题
kimi、kimi web 和 kimi acp。