人 + AI 软件创建：面向未来的实用手册

“人 + AI” 软件创建真正意味着什么

“人 + AI” 软件创建是共创：团队在构建软件的同时，使用 AI 工具（如编码助手和大型语言模型）作为贯穿过程的主动帮手。这不是完全自动化，也不是“按下一个按钮就有产品”。把 AI 想象成一个快速的合作者，它可以起草、建议、检查和总结——而人类负责决策和结果。

共创 vs 完全自动化（通俗说法）

共创意味着人来设定目标、定义什么是“好”，并引导工作。AI 带来速度和选项：它能建议代码、生成测试、改写文档，或提示边缘情况。

完全自动化则意味着 AI 承担端到端的产品工作，几乎无需人类指引——需求、架构、实现与发布均由 AI 主导并承担问责。大多数团队并不追求这种方式，且大多数组织也无法接受相关风险。

为什么协作符合真实团队的模式

软件不仅仅是代码。它还包含业务语境、用户需求、合规、品牌信任以及错误的成本。AI 在生成草稿和探索替代方案上非常擅长，但它无法真正理解你的客户、内部约束或公司可安全交付的内容。协作既保留了 AI 的优势，又确保产品与现实目标保持一致。

设定期望：更快的迭代，新出现的故障模式

你应当期待在起草和迭代上获得显著的速度提升——尤其是对重复性工作、样板代码和第一版解决方案。同时，质量风险会以不同方式出现：自信却错误的回答、微妙的 bug、不安全的模式，以及许可或数据处理方面的失误。

人类仍然掌控：

• 产品意图与优先级
• 权衡（成本、可靠性、安全性、可维护性）
• 最终审查、批准与问责

本手册将涵盖的内容

接下来的章节将带你通过一套实用工作流：把想法变成需求、共同设计系统、与 AI 结对编程、测试与代码审查、安全与隐私护栏、保持文档更新、以及衡量结果以便下一轮迭代不仅更快而且更好。

AI 最有帮助的场景——以及人类必须主导的地方

AI 擅长加速执行——把清晰的意图转成可用的草稿。人类仍然最适合最初定义意图，并在现实复杂时做决策。

AI 可以加速的任务

如果使用得当，AI 助手可以在以下方面节省时间：

• 起草样板（端点、CRUD、UI 脚手架、配置）
• 重构（重命名、提取函数、简化逻辑）
• 编写测试（建议边缘情况、生成测试骨架）
• 文档（README 草稿、API 使用示例、发布说明）
• 调试支持（总结日志、提出可能原因、建议实验）
• 代码搜索与解释（总结不熟悉的模块与流程）

主题：AI 在生成候选项方面很快——代码草稿、文本草稿、测试用例草稿。

人类最能带来价值的地方

人类应当主导：

• 明确目标与成功指标（“完成”意味着什么）
• 选择权衡（速度 vs 成本、一致性 vs 灵活性、自研 vs 购买）
• 产品判断（用户真正需要什么、什么可以延后）
• 架构与风险决策（可操作性、可扩展性、故障模式）
• 问责（对行为、数据处理和质量签字担责）

AI 能描述选项，但不拥有结果。所有权属于团队。

AI 的输出是建议——不是事实来源

把 AI 当作一个会迅速且自信起草的聪明同事，但它仍可能出错。用测试、审查、基准和对真实需求的快速核对来验证它的输出。

一个简单的“好”用法 vs “坏”用法

好用法：“这是我们现有的函数和约束（延迟 < 50ms，必须保留顺序）。提出一个重构方案，解释权衡，并生成证明等价性的测试。”

坏用法：“为我们重写认证中间件以提高安全性”，然后把输出直接复制到生产而不理解它、没有进行威胁建模或用测试验证。

真正的收益不是让 AI 驱动，而是让 AI 加速那些你已知如何引导的部分。

明确的劳动分工：角色、所有权与问责

当每个人都清楚自己负责什么与不负责什么时，人 + AI 协作效果最佳。AI 可以快速起草，但不能对产品结果、用户影响或业务风险承担问责。明确的角色能防止“AI 说了就这样”的决策，并让团队更有信心地前进。

角色清晰：谁负责什么

把 AI 想成支持各职能的高速贡献者，而不是替代者。

• 产品 负责目标、范围与优先级。AI 可以帮助总结研究、起草用户故事并提出验收标准。
• 设计 负责用户体验、无障碍与交互决策。AI 可以生成变体、评估流程并起草文案选项。
• 工程 负责架构、实现、可靠性与长期可维护性。AI 可以建议方法、起草代码并协助调试。
• AI（工具） 暂时不承担所有权——它能加速起草、提示风险并提供替代方案。人类必须验证。

轻量责任矩阵（决定 / 起草 / 验证）

使用简单矩阵避免工单与 PR 中的混淆：

合并或发布前的审查门控

加入明确门控以免速度超过质量：

1. 规范门控： 问题、范围与验收标准达成一致。\n2. 设计门控： 关键界面/流程获批（含无障碍检查）。\n3. 实现门控： PR 有人工审查；AI 仅作建议。\n4. 安全门控： 测试通过；完成相关安全/隐私检查（如适用）。\n5. 发布门控： 编写变更日志；确认监控/回滚计划。

让决策可见（并可审计）

把“为什么”记录在团队常用的地方：工单评论记录权衡、PR 说明记录 AI 生成的变更、以及发布的简明变更日志。决策可见时，问责也就清晰了，未来的工作也更容易。

从想法到需求：共同编写产品规格

好的产品规格不是“把一切写下”，而是让人对将要构建的内容、原因和“完成”含义达成一致。有 AI 参与时，你可以更快达成清晰、可测试的规格——前提是由人来对决策负责。

从问题开始，而不是功能

先用清晰语言写下三条锚点：

• 问题陈述： 我们在减少什么用户痛点或业务风险？\n- 成功指标： 我们如何判断它有效（节省时间、转化、减少工单、收入影响）？\n- 约束： 预算、时间线、支持的平台、数据源与“不得为”规则。

然后请 AI 挑战草稿："我做了哪些假设？什么会让这个方案失败？在工程开始前我应该回答哪些问题？" 把输出当成需要验证的待办清单，而非真理。

用 AI 提出方案并揭示权衡

让模型生成 2–4 个方案（包括“什么都不做”的基线）。要求其指出：

• 依赖项（系统、团队、供应商）\n- 风险与未知项\n- 预期工作量范围\n- 需要用户研究或法律审查的内容

你来选择方向；AI 帮你看到可能忽略的点。

把想法变成简短的 PRD 大纲

保持 PRD 精简以免没人愿意读：

• 目标与非目标\n- 目标用户与关键场景\n- 范围（MVP 与后续）\n- 验收标准（可测试陈述，不要模糊承诺）

示例验收标准："登录用户能在 10 秒内导出 CSV，数据集最大 50k 行。"

需求检查表（别跳过）

在规格被视为就绪之前，确认：

• 隐私与数据处理： 使用、存储、共享与保留的数据是什么\n- 合规： 行业规则与内部政策\n- 性能： 响应时间、吞吐量、扩展预期\n- 无障碍： WCAG 目标、键盘导航、屏幕阅读器支持

当 AI 起草 PRD 的部分时，确保每个需求都能追溯到真实用户需求或约束，并由明确的负责人签字。

共同设计系统：方案、权衡与决策

系统设计是“人 + AI”协作最有力的地方之一：你可以快速探索几种可行架构，然后用人的判断选择最适合现实约束的方案。

用 AI 生成选项——然后迫使它做比较

要求 AI 给出 2–4 个架构候选（例如：模块化单体、微服务、无服务器、事件驱动），并在成本、复杂度、交付速度、运行风险和供应商锁定等维度上做结构化比较。不要接受单一的“最佳”答案——让它两面论证。

一个简单的提示模式：

• “为 X 提出三种架构；列出假设。”\n- “用表格比较：成本/复杂度/风险。”\n- “在生产中什么会导致每个选项失败？”

绘制接缝：集成点、数据流、故障模式

选定方向后，让 AI 列出系统接触点。要求它产出：

• 集成点（API、队列、Webhook、批量导入）\n- 数据流（哪些数据为什么流向哪里）\n- 故障模式（超时、重试、重复事件、部分写入）

然后请人验证：这些是否匹配你公司的真实运营，包括边缘情况和凌乱的真实世界数据？

保持决策日志，避免随人员流动丢失知识

创建轻量的决策日志（每个决策一页），记录：

• 背景与约束\n- 考虑的选项\n- 决策及其原因\n- 接受的权衡\n- 后续（要衡量的内容、何时复审）

把它存放在代码仓旁以便发现（例如放在 /docs/decisions 中）。

早点定义不可谈判项

实现前写下安全边界和数据处理规则，这些不能被“优化”抹去，例如：

• 敏感数据可存储与处理的地点\n- 认证/授权模型与信任边界\n- 日志/脱敏要求\n- 保留与删除期望

AI 可以起草这些策略，但人类必须拥有它们——因为问责不能被委托。

与 AI 的结对编程：实用的构建工作流

把模型当作初级合作者：它善于产生选项，但对你独特的代码库理解薄弱，除非你教它。目标不是“让 AI 写完应用”，而是建立一条紧密循环：人来把关，AI 来加速。

如果你想让这个工作流看起来比独立编码助手更“端到端”，像 Koder.ai 这类 vibe-coding 平台可以帮忙：在聊天中描述功能、以小步迭代，同时保留人工审查门控——平台能为 Web（React）、后端服务（Go + PostgreSQL）或移动应用（Flutter）生成可导出的源码。

第一步：用真实上下文设置舞台

在请求代码之前，提供那些人在查看仓库时自然了解的约束：

• 相关文件（或关键摘录）与文件夹结构\n- 命名约定、lint/格式规则与偏好的库\n- 不可妥协项（性能、无障碍、安全、API 版本）\n- 该切片的“完成定义”（预期输入/输出、边缘情况）

一个简单的提示模板有助于：

You are helping me implement ONE small change.
Context:
- Tech stack: …
- Conventions: …
- Constraints: …
- Existing code (snippets): …
Task:
- Add/modify: …
Acceptance criteria:
- …
Return:
- Patch-style diff + brief reasoning + risks

（注：上方代码块为原始提示模板，保持原样以便复用。）

第二步：做小切片，而不是大改写

把范围保持微小：一个函数、一个端点、一个组件。小切片更容易验证行为，避免隐藏回归，并保持所有权清晰。

一个良好节奏是：\n1) 你描述意图与边界。\n2) AI 提出脚手架（文件、接口、连线）。\n3) 你选择方案并请求下一个增量变更。

第三步：让 AI 做重复性工作——然后你润色

AI 在生成样板、映射字段、生成强类型 DTO、创建基础 UI 组件以及执行机械重构方面表现出色。人类仍应：

• 根据产品意图验证正确性\n- 简化并为事物命名\n- 与架构和长期可维护性对齐

第四步：禁止悄然复制粘贴到生产

制定规则：生成代码必须像任何贡献一样被审查。运行它、阅读它、测试它，确保其符合约定与约束。如果你不能解释它如何工作，就不要发布它。

测试作为共同的安全网

测试是“人 + AI”协作最务实的地方。AI 可以生成想法、脚手架和大量用例；人类提供意图、判断与问责。目标不是更多测试，而是更高的信心。

让 AI 扩展你的思考（特别是边缘情况）

一个好的提示可以把 LLM 变成不知疲倦的测试伙伴。要求它提出你可能遗漏的边缘情况与故障模式：

• 边界值（空输入、最大长度、奇怪编码）\n- 与时间相关的怪异情况（时区、夏令时、时钟漂移）\n- 并发与重试（重复提交、部分失败）\n- 权限与角色组合

把这些建议当作假设而非真理。人类根据产品风险与用户影响决定哪些场景重要。

用 AI 起草测试——然后验证其含义与覆盖率

AI 能快速起草单元与集成测试，但你仍需验证两点：

1. 覆盖率： 测试是否覆盖重要行为，还是仅覆盖 happy path？\n2. 含义： 断言是否证明了正确的事情，还是脆弱的快照，会引入噪音？

一个实用流程是：你用普通语言描述预期行为，AI 提出测试用例，然后你把它们精炼成小而可读的测试套件。如果一个测试难以理解，那可能说明需求不清晰。

明智地生成测试数据（并保证安全）

AI 可以生产看似真实的测试数据——姓名、地址、发票、日志——但切勿用真实客户数据作为种子。优先使用合成数据、匿名化夹具并明确标注为“假数据”。在受监管场景下，记录测试数据的生成与存储方式。

将“完成”重新定义为超越“能编译”

在 AI 辅助的构建循环中，代码可能很快看起来“完成”。把“完成”设为共享契约：

• 本地与 CI 测试通过\n- 新行为有新增/更新的测试\n- 有人工审查测试意图与风险覆盖范围

这个标准能防止速度超过安全，并使 AI 成为乘数而非捷径。

使用 AI 的代码审查：更快的反馈，同样的标准

AI 可以在“第一遍”审查中加速工作：总结变更、标记不一致并提出小改进。但它并不改变代码审查的目的。标准保持不变：保护用户、保护业务并维持代码库的可演进性。

在人工打开 diff 之前 AI 能做什么

应用得当时，AI 助手成为预审清单生成器：

• 总结变更： “这个 PR 做了什么，通俗地说？涉及哪些文件与行为？”\n- 发现不一致： 命名不匹配、逻辑重复、缺失的错误处理、惊人的默认值。\n- 建议改进： 更严格的校验、清晰的变量名、更简单的控制流、更好的注释。

在大 PR 中尤其有价值——AI 能指出 3–5 个真正带来风险的区域，吸引审查者重点关注。

人审者必须核实的内容

AI 可能以自信的方式出错，因此人类仍要对以下内容负责：

• 正确性： 是否满足需求？边缘情况是否考虑？故障模式是否可接受？\n- 安全与隐私： 是否存在注入风险、不安全的反序列化、授权缺口或密钥泄露？\n- 可维护性： 是否可读？是否符合架构？是否可测试？值班工程师在凌晨两点能理解吗？

一个有用的规则：把 AI 的反馈当成聪明的实习生——可以使用，但对重要内容要全部验证。

审查者可以使用的提示

粘贴 PR diff（或关键文件）并尝试：

• “总结行为变更并列出用户可见的影响。”\n- “找出风险假设或与其他模块的隐藏耦合。”\n- “识别安全问题并指出具体行数。”\n- “哪些边缘情况未被测试覆盖？”\n- “建议在不改变行为的前提下减少复杂性的重构。”

在 PR 中透明记录 AI 的使用

要求作者在 PR 中添加简短说明：

• AI 做了什么： 生成了某个函数、建议了正则、改写了错误处理、起草了测试。\n- 人工验证了什么： 满足需求、添加/更新了测试、完成了安全检查、手动测试步骤。

这种透明度把 AI 从黑盒变成团队工程流程的可记录部分。

安全、隐私与许可：关键护栏

AI 能加速交付，但也会加速出错。目标不是“更少信任”，而是以明确护栏来更快验证，以保持质量、安全与合规。

需要规划的关键风险领域

幻觉（hallucinations）： 模型可能编造 API、配置标志或关于代码库的“事实”。\n\n不安全模式： 建议可能包含危险默认（如过宽的 CORS、弱加密、缺失的授权检查）或常见但有风险的片段。\n\n许可不确定性： 生成的代码可能类似于有许可证的示例，AI 建议的依赖可能引入病毒式许可证或限制性条款。

实用护栏（将其设为非可选）

把 AI 输出当做任何第三方贡献来处理：

• 在 CI 中做依赖扫描（SCA）以捕捉易受攻击的包与被禁止的许可证\n- 在每个 PR 上运行 SAST 以标记注入、认证缺陷、不安全反序列化与危险的 Sink\n- 在预发布环境做 DAST（或至少对 API 做模糊/烟雾安全测试）以获得运行时信号\n- 在提交和构建日志中做密钥检测；若泄露则失败构建\n- 对高影响改动（认证、支付、数据导出）做轻量威胁建模检查点

把发现结果展示在 PR 检查中，让安全成为“完成”的一部分，而非单独阶段。

提示中敏感数据的规则

写下并执行这些规则：

• 绝不粘贴 凭证、私钥、令牌或会话 Cookie。\n- 绝不粘贴 客户数据、个人数据或含标识符的生产日志。\n- 避免 私有源码，除非你的工具与合同明确允许。\n- 优先使用脱敏示例和合成测试数据。

当 AI 与需求冲突时：简单升级路径

如果 AI 建议与规格、安全策略或合规规则冲突：

1. 工程师在 PR 中标注（“AI 建议与需求 X 冲突”）。\n2. 重新检查规格并补充澄清说明或验收标准。\n3. 升级到代码负责人/安全评审者以作最终决定。\n4. 把结果记录成团队文档中的一条简短规则，避免同样冲突重复发生。

保持文档与知识共享的现状

好的文档不是单独项目——它是团队如何构建、发布和支持软件的“操作系统”。最佳的人 + AI 团队把文档视为一等交付物，并用 AI 保持其与现实的一致性。

AI 应起草哪些内容（并由人完成最终校对）

AI 很擅长产出可用的首稿：

• 运行手册（runbooks）： 针对事故与常见运维任务的逐步指南。\n- 入职说明： “如何在本地运行项目”、关键概念和重要文件夹地图。\n- 决策摘要： 为什么做出某个权衡的简短记录，通俗易懂。

人类应核验准确性、去除假设并补充只有团队知道的上下文——比如什么是“好”的样子、哪些是风险和哪些是刻意不在范围内的决定。

把技术工作转成人人能读的发布说明

在一次冲刺或发布后，AI 可以把提交与 PR 翻译成面向客户的发布说明：发生了什么、为什么重要、是否需要执行任何操作。

实用模式是把一组经挑选的输入（已合并的 PR 标题、问题链接和一段“重点是什么”的简短说明）交给 AI，请求两个输出：

1. 面向非技术读者的版本（产品、销售、客户）\n2) 面向运维的版本（支持、值班、内部团队）

然后由人工负责编辑语气、准确性与措辞。

防止文档漂移

文档之所以过时，是因为它与代码变更脱节。把文档与工作绑定：

• 在同一个 PR 中更新文档或标注不需要更新\n- 在 PR 检查列表加入轻量项："已更新文档或无需更新"\n- 在代码审查中使用 AI 检测潜在漂移（例如：重命名的端点、配置变化、新增标志）

如果你维护产品站点，使用内部链接减少重复问题，并指向稳定资源，例如 /pricing（计划详情）或 /blog（支持文档的深度解析）。

衡量结果并为下一波变革做准备

如果你无法衡量 AI 辅助的影响，就只能靠主观感觉争论：“感觉更快” vs “感觉更危险”。把人 + AI 的交付当成任何其他流程变更来对待——为其打点、评审并调整。

测量什么（以及为什么）

先从一小组反映真实结果的指标开始，而不是追求新奇：

• 前置时间（从想法到生产）： 你是在更快交付，还是只是产生更多草稿？\n- 缺陷与外泄： 跟踪 bug 率、严重度和到达客户的问题数量。\n- 事故： 频率、检测时间、恢复时间与事后跟进。\n- 满意度： 针对开发者与利害关系人的短脉冲调查（清晰度、自信、感知质量）。

把它们与审查吞吐量（PR 周期时间、审查轮次）配对，以观察 AI 是否在减少瓶颈或增加返工。

跟踪 AI 有帮助的领域与增加返工的领域

不要以道德化方式给任务贴“AI”或“人类”标签。给它们贴标签是为了学习。

实用方法是在工作项或 PR 上用简单标记：

• AI 用于 样板/脚手架\n- AI 用于 重构\n- AI 用于 测试生成\n- AI 用于 调试

然后比较结果：AI 辅助的变更是否更快获批？是否触发更多后续 PR？是否与回滚相关联？目标是识别高杠杆区（高收益）与危险区（高返工）。

如果你在评估平台（不仅仅是助手），把“返工减少器”列入考量——如快照/回滚、部署/托管以及导出源码的能力。这也是团队在原型之外使用 Koder.ai 的一个原因：你可以在聊天中快速迭代，同时保有常规控制（审查、CI、发布门控），并保持向标准仓库的干净出口策略。

建立紧密的反馈回路

创建一个轻量的团队“学习系统”：

• 共享 提示库（何时问、如何问、带哪些上下文）\n- 一组 优秀输出（什么是“完成”的样例）\n- 一组 差劲输出（幻觉、不安全模式、误导性测试）以及这些问题如何被发现

保持实用且即时——在回顾中更新，而不是把它当成季度性的文档工程。

为下一阶段做准备

预期角色会演变。工程师将更多地从事问题框定、风险管理与决策制定，而减少重复将意图翻译为语法的工作。新的技能变得重要：编写清晰规格、评估 AI 输出、理解安全/许可约束，以及通过示例教导团队。持续学习不再可选——它成为工作流的一部分。