Kimi 氛围编程教程：无需编写代码即可构建产品变得更容易，但发布并非如此

Kimi 将曾经高度技术化的工作流程转变为对话式流程，但这一转变也在快速构建与负责任地发布之间制造了新的冲突。本 Kimi 氛围编程教程通过一段完整的产品旅程来审视这种冲突，从最初的规格说明一直到公开部署。

重要的变化并不在于 AI 模型能够生成落地页。如今，编码智能体可以检查项目文件、编辑多个组件、执行命令、运行测试，并在失败后调整计划。Kimi Code、Qwen Code 和基于 GLM 的编码服务将这套工作流程带入终端和开发环境。

这让初次构建产品的人处于一种不同寻常的境地。他们可以在尚未理解底层系统之前，开发出更多软件。然而，托管、身份验证、数据库、安全、域名配置和监管义务仍然是工程问题。

Andrej Karpathy 在 2025 年 2 月为这种实践起了一个令人难忘的名字。他的描述强调接受生成的变更，并暂时忘记代码的存在。这种态度适用于实验性的周末项目，但公开发布的产品需要遵循不同的标准。

真正有用的问题已不再是没有编程经验的人能否构建应用程序。他们可以。更难的问题是：在智能体创建应用程序后，他们能否理解、测试、运营应用程序，并在出现故障时将其恢复。

Kimi 编码智能体如今处理的不只是代码生成

从聊天助手转向编码智能体，改变了谁能够启动软件项目，但并没有免除构建者的责任。

聊天模型通常返回文本或孤立的代码示例。编码智能体则可以在项目内部工作、检查项目结构、修改文件、运行命令并观察最终输出。这种反馈循环让系统能够在给出第一个答案后继续推进。

这种区别对非技术构建者十分重要。在浏览器和编辑器之间复制代码，需要知道每个代码片段应该放在哪里。智能体能够定位相关文件，并协调界面、服务器、数据库和配置之间的变更。

Kimi 将其命令行客户端描述为一种能够读取和修改代码、搜索文件、执行 shell 命令，并根据反馈修订计划的智能体。其当前的 Kimi Code 指南还说明了客户端如何在扫描项目后生成 AGENTS.md 文件。

该文件充当智能体的运行上下文。它可以记录项目结构、构建命令、约定，以及其他需要在不同任务之间持续保留的指令。智能体因此获得了一张地图，而不再将每个提示词视为孤立的请求。

Qwen Code 采用了类似的模式。其智能体概述介绍了一种终端工具，可以将产品指令转化为代码，并支持脚本化的非交互式使用。它还可以通过多种身份验证和模型提供商选项进行连接。

这些产品体现了软件开发界面的一次更大变革。用户描述行为、约束和验收标准，智能体则将这些意图转化为文件、命令和测试。

然而，自然语言并不是完整的规格说明。诸如“构建一个客户门户”这样的请求留下了许多尚未回答的关键问题。它没有说明账户恢复、访问权限、数据保留、支付失败、审计日志或滥用防范。

经验丰富的工程师能够注意到这些缺口，因为它们与以往的失败十分相似。初学者往往只看到可见的界面，并以为系统已经接近完成。编码智能体缩短了实现时间，但也可能将尚未完成的决策隐藏在精美的界面背后。

这篇源自 AIHOT 的中文指南很好地概括了这种新工作流程。它将包括 Kimi、GLM 和 Qwen 在内的国内模型视为从构想到产品上线的便捷途径。其中最有力的建议出现在接近结尾的位置：构建者可以避免编写代码，但无法避免理解架构。

这种区别应该成为所有严肃的 Kimi 氛围编程教程的核心。智能体可以执行任务，而人类仍须负责定义系统，并判断它是否正常运行。

首次输入提示词之前必须先制定产品规格说明

模糊的想法会产生一个有说服力的演示，而边界清晰的规格说明才能让智能体有机会产出可运营的产品。

第一项交付成果不应该是代码，而应该是一份简短的产品规格说明，涵盖用户、任务、数据、权限、失败状态和成功标准。当智能体开始作出假设时，这份文档将成为参考依据。

从一个用户和一项任务开始。“自由职业者需要将会议记录转化为发给客户的跟进内容”，比“构建一个 AI 生产力平台”更具可执行性。范围更窄的表述明确了输入、转换过程和输出。

接下来，定义最小但完整的用户旅程。用户创建账户、导入笔记、查看生成的跟进内容、对其进行编辑，然后导出结果。每一步都应该包括用户会看到什么，以及操作失败时会发生什么。

数据应该有单独的章节。列出应用程序存储的每种信息、信息来源、谁可以读取，以及何时应该删除。敏感文档所需的保护措施不同于公开的目录数据。

权限也需要使用明确的语言定义。管理员、普通用户和匿名访客不应该拥有相同的能力。如果产品支持团队，请说明成员是否可以查看彼此的记录，以及谁可以撤销访问权限。

然后将系统定义为多个组件：

• 界面用于显示页面、表单、导航和反馈。

• 应用程序服务负责执行业务规则并协调请求。

• 数据库用于存储用户、记录、权限和状态。

• 身份验证负责验证身份并控制会话。

• 外部服务提供电子邮件、支付、AI 推理或文件存储功能。

• 托管服务使应用程序可供访问，并提供日志、网络和备份。

初学者无需在开始之前了解每个实现细节，但确实需要认识这些组件，并询问每项职责由哪里承担。否则，智能体可能会悄无声息地将不相关的关注点组合成脆弱的代码。

计划模式在这一阶段很有用。不要要求智能体立即开始构建，而应让它检查规格说明、找出尚未作出的决策、提出架构方案，并将工作划分为多个里程碑。

智能体的计划应该列出主要的数据实体、路由、依赖项和测试策略，同时还应说明其假设。多个功能一旦依赖于隐含假设，修正这些假设的成本就会变得高昂。

要求智能体在不展示代码的情况下描述架构。如果解释仍然令人困惑，那么产品还不适合自主实现。继续修改计划，直到你能用通俗语言解释请求流程。

有效的提示词需要定义证据，而不是表达热情。“添加登录功能”并不完整。“添加电子邮件登录、拒绝已过期的会话、防止用户访问其他账户的记录，并为这些情况编写测试”则建立了可观察的要求。

同样的原则也适用于界面工作。描述空状态、加载状态、验证错误、小屏幕、键盘导航和破坏性操作。一个只能处理理想数据的生成式仪表盘仍然只是模型。

构建者可以将需求、来源笔记、模型决策和测试观察结果保存在可搜索的 AI 工作流程中。当智能体询问之前为何作出某项架构选择时，这些上下文将非常有价值。

规格说明会在开发过程中发生变化，这是正常的。重要的规则是：在要求智能体实现新方向之前，先更新源文档。

从计划到可运行构建的 Kimi 氛围编程教程

最安全的智能体工作流程会采用小型且可验证的里程碑，而不是用一条提示词要求构建整个应用程序。

在开始主要实现工作之前，先在受版本控制的代码仓库中创建项目。版本控制会以提交的形式记录变更，让构建者能够比较不同版本，并恢复到较早的状态。首次提交应包含规格说明和最小化的项目框架。

要求智能体以简化运维为依据提出技术栈。答案应解释每个组件存在的原因、如何部署，以及为何排除其他替代方案。不要仅仅因为模型最先生成了某个框架，就选择它。

第一个里程碑应该搭建应用程序框架，包括开发命令、环境配置、基本导航、健康检查和测试命令。在另一个全新的环境能够运行该框架之前，不应继续开发任何业务功能。

第二个里程碑应该实现核心数据模型。在生成迁移文件之前，要求智能体展示实体、实体之间的关系和所有权规则。迁移是受控的数据库变更，可以在不同环境中以一致的方式应用。

用通俗语言审查数据库结构。哪条记录属于哪个用户？删除账户时会发生什么？两条记录是否可能意外引用不存在的数据？这些答案可以揭示底层模型是否与产品相匹配。

第三个里程碑是添加身份验证和授权。身份验证回答用户是谁，授权回答该用户可以做什么。许多生成式应用程序实现了前者，却将后者视为界面层面的事项。

服务器必须针对每一项受保护的操作强制执行授权。隐藏按钮并不等于访问控制。恶意或好奇的用户无需使用预期的界面，也可以直接发送请求。

第四个里程碑是实现一条完整的产品使用路径。在核心路径正常运行之前，应避免添加设置页面、分析面板或视觉优化。一条狭窄的垂直切片能够更早暴露集成问题。

每项任务完成后，要求智能体总结：

• 它更改的文件

• 它添加的行为

• 它作出的假设

• 它运行的测试

• 仍然需要人类判断的测试

• 任何安全或部署方面的后果

每个里程碑完成后都要运行应用程序。先尝试预期行为，然后以不当方式使用它。提交空白表单、超大输入、重复请求、已过期的会话、无效 URL，以及其他用户的记录标识符。

出现问题时，报告观察到的行为，而不是要求智能体“修复所有问题”。包括命令、预期结果、实际结果和相关日志输出。精确的反馈有助于模型区分程序缺陷与被误解的需求。

不要默认接受用大范围重写来解决局部错误。要求提供根本原因解释和最小化补丁。大规模的生成式变更更难审查，也可能移除原本正常运行的行为。

每个经过验证的里程碑完成后都要提交。使用能够说明产品变更的描述，而不是记录对话过程。清晰的历史记录可以让你在智能体引入多个相互关联的错误时，返回到已知的稳定状态。

当上下文变得混乱时，开启一个全新的代理会话。向新会话提供规格、架构、当前里程碑以及经过验证的仓库状态。产品发生变化后，长对话可能仍会保留已经过时的假设。

这种分阶段方法看起来比一次性生成更慢。实际上，它减少了精心打磨的应用在部署过程中崩溃所造成的高昂返工成本。目标不是让每次提示都输出最多的代码，而是让每次变更都取得最多经过验证的进展。

部署将演示原型变成一个需要持续运转的系统

正式上线会带来基础设施、身份、监管和恢复方面的职责，而编码代理无法亲自承担这些职责。

本地应用在条件友好的单台机器上运行。公开部署则会面临不可预测的流量、格式错误的请求、自动化扫描以及真实用户数据。这种环境改变了“能够运行”的含义。

将开发环境与生产环境分开。开发环境用于实验。生产环境是实际用户所依赖的系统。二者不应共用同一个数据库、凭据或不受限制的管理权限。

通过环境变量或托管式密钥服务存储配置。绝不要将数据库密码、API 密钥或签名密钥放入源文件。上线前，让代理扫描仓库历史记录，检查是否意外提交过凭据。

根据应用的组件选择托管方案。静态界面、长期运行的服务器、计划任务和关系型数据库有着不同的需求。部署计划应明确每个组件如何启动、通信、记录错误和重启。

域名会增加另一个层面。它的 DNS 记录将用户指向托管服务，而 TLS 会加密连接。产品还需要制定重定向其他域名形式和续订证书的策略。

托管在中国大陆境内的产品可能还需要履行额外的备案义务。中国修订后的 ICP 备案规则规定，在境内提供非经营性互联网信息服务，必须履行备案手续。

该规则还规定，完整的备案申请应在 20 个工作日内收到备案决定。这是监管规定的最长期限，并不保证每次上线都能按照固定进度完成。构建者应将备案视为需要尽早启动的一项工作。

具体义务取决于服务类型、托管安排、商业模式和司法管辖区。编码代理可以整理相关要求，但无法提供具有权威性的法律许可意见。如果适用范围不明确，请咨询相关服务提供商和具备资质的法律顾问。

部署还需要数据库迁移控制。应用破坏性变更前，应备份生产数据。使用具有代表性的数据测试迁移，并记录如何撤销迁移。

创建一份发布检查清单，涵盖构建成功、自动化测试、安全检查、迁移、配置、监控和回滚。每一项都应提供证据，而不是依赖代理的口头保证。

日志应能回答发生了什么故障、故障发生在何时，以及哪些操作受到影响。日志不应暴露密码、令牌、私人文档或非必要的个人信息。记录更多数据并不一定更安全。

监控应覆盖基本可用性、服务器错误、延迟、失败的后台任务和存储限制。每条告警都需要明确的人类负责人和响应路径。无人理解的通知只会增加噪声。

备份需要通过恢复测试进行验证。备份任务成功只能证明数据被复制到了某个位置，并不能证明产品可以在可接受的时间内恢复。

邀请用户之前，应准备一条回滚路径。这可能意味着恢复到上一个版本、禁用新功能或撤销迁移。团队应知道每种可能的故障分别适用哪种操作。

正是在这里，“无代码”这一描述开始产生误导。构建者可能不必亲自输入实现代码，但他们仍在运营一个伴随技术和组织责任的系统。

AI 生成的代码需要分支保护和对抗性测试

代理的自信不能证明产品是安全、正确或已准备好投入生产的。

2025 年 Stack Overflow 开发者调查发现，人们对 AI 输出存在明显的信任鸿沟。虽然 84% 的受访者正在使用或计划使用 AI 工具，但 46% 的人不信任其准确性。只有 33% 的人表示信任。

同一份开发者调查发现，66% 的人对那些几乎正确的 AI 解决方案感到沮丧。另有 45% 的人将耗时的生成代码调试列为主要困扰。

这些数据并不表明编码代理没有价值。它们说明了为什么验证工作必须随着采用规模的扩大而加强。当变更扩散到系统中不熟悉的部分时，更快的生成速度可能带来更繁重的审查负担。

初始项目设置完成后，应保护主分支。GitHub 的分支保护可以要求变更在合并前必须通过拉取请求、状态检查、讨论解决或审批审查。

即使是独立构建者也能从这种结构中获益。代理在单独的分支上工作，自动化检查随之运行，构建者在合并前审查摘要。这种暂停在代码生成与发布之间建立了一道边界。

自动化流水线至少应从锁定文件安装依赖项、构建应用、运行测试并执行面向安全的检查。失败应阻止合并，而不是变成埋藏在日志中的警告。

测试应在多个层面开展：

• 单元测试检查独立的业务规则。

• 集成测试检查与数据库和外部服务的通信。

• 端到端测试检验完整的用户流程。

• 授权测试确认一个账户无法访问另一个账户的数据。

• 迁移测试检查架构变更是否保留现有记录。

• 手动测试检查可用性、模糊输出和意外行为。

让代理在修复已确认的缺陷之前先编写测试。失败的测试可以捕捉问题，并降低问题再次出现的可能性。然后要求同一测试在补丁应用后通过。

安全需要单独进行一轮威胁建模。威胁模型用于识别有价值的资产、潜在攻击者、暴露的入口点和可能的滥用方式。它将“确保安全”转化为一组具体问题。

如果用户修改请求中的标识符，会发生什么？上传的内容能否执行代码？服务器是否会获取外部 URL？重复尝试密码是否不受限制？管理路由是否会在服务器端检查角色？

OWASP 警告称，AI 生成或由普通用户开发的系统可能会重复使用存在漏洞的组件，甚至引用不存在的软件包。其关于不可信组件的指南建议，将生成的依赖项视为需要验证的项目。

检查每一个新增依赖项。确认软件包确实存在、来自预期的发布者、仍在维护，并且具有必要用途。一个看似合理的软件包名称并不能证明其合法性。

使用依赖项锁定文件，并避免不必要的软件包。更少的依赖项可以减少可能发生故障、所有权变更或引入漏洞的外部组件数量。

生成的身份验证代码需要特别审查。密码存储、会话处理、重置流程、Cookie 设置和授权检查都包含安全敏感的细节。应优先选择成熟且有文档记录的实现，而不是自定义逻辑。

早期测试期间绝不要使用真实客户数据。生成与必要结构相似的合成记录，同时避免暴露个人信息。即使项目只有一个运营者，也应限制生产环境访问权限。

AI 功能会带来额外风险。如果用户内容会进入模型提示，应将这些内容视为不可信。它可能尝试覆盖指令、泄露隐藏的上下文或触发非预期工具。

拥有文件和命令访问权限的代理也具有很高的本地权限。审查其请求执行的操作、限制凭据，并避免在日常开发期间授予生产环境访问权限。便利性不应抹去运营边界。

对于处理资金、健康信息、机密文档或敏感身份数据的产品，非技术创始人应在上线前安排独立审查。生成代码的代理不应成为审查自身工作的唯一审查者。

上线后构建者应关注什么

检验氛围编程的决定性标准，不是代理能否发布第一个版本，而是人类能否运营第二个版本。

第一个指标是变更可靠性。跟踪所请求的功能通过测试、进入生产环境并在无需回滚的情况下持续运行的频率。频繁撤销表明架构或验证流程无法支撑代理的开发速度。

第二个指标是事件责任归属。出现告警时，构建者应能识别受影响的组件、检查相关日志并解释故障路径。完全依赖另一个代理的回复，会让产品缺乏负责任的诊断主体。

第三个指标是模型可移植性。Kimi、Qwen、GLM 和其他编码系统将继续改变其客户端、模型、身份验证方式和限制。拥有清晰文档和标准工具的仓库可以更轻松地在不同代理之间迁移。

模型可移植性并不意味着每个代理都会生成相同的代码。它意味着项目的需求、架构、命令和测试足够明确，使其他工具或工程师能够继续开展工作。

构建者还应关注可见输出与运营质量之间的差距。新的界面页面很容易展示。更低的错误率、更安全的迁移、更快的恢复速度和更清晰的权限不那么显眼，却更为重要。

因此，这篇 Kimi 氛围编程教程最终给出了一种不同的成功定义。成功并不是在不接触编程语言的情况下获得一个可访问的网址，而是构建出一个你能够解释其行为、数据、风险和恢复路径的线上系统。

从一条用户流程开始，在打开编码代理之前写下其需求。让代理制定计划、实现一个里程碑，并提供测试证据。只提交经过验证的变更，然后在邀请真实用户之前建立部署和恢复控制。

如果你无法解释身份在哪里进行检查、数据存储在哪里，或如何撤销失败的发布，请暂停上线。让代理梳理这些系统，直到答案变得清晰。氛围编程可以降低实现成本，但无法将产品责任转移给模型。