AI 原生一人公司操作手册

如果只看一段话，看这一段。

AI 原生公司的运转方式，可以用一条链概括。链上的每一环都是一份具体、可被人和 agent 同时读取的产物，而不是一次对话、一个脑内决定：

链条的价值在于：它同时是执行流程和审计链。任何一个环节出了问题，你都能沿着链往回追到「谁提了什么、agent 产出了什么、谁批准了」。

先接受一个事实：写、做、产出这件事，已经不值钱了。

过去一百年，组织设计的基本假设是「执行稀缺」：能写代码的人少，能做交付的人少，于是我们用流程、层级和会议去保护稀缺的执行产能。招聘、培训、绩效——大量管理动作本质是在优化执行效率。

这个假设现在被推翻了。当 agent 能以极低成本完成检索、起草、生成、比对、同步这些动作时，执行不再是需要被保护的东西——它变成了可以随意放大的资源。

瓶颈往后移动，而不是消失

真实的观察来自公开的工程数据：当一家头部实验室让模型承担大部分代码产出后，工程师的交付量上去了，但测试量、CI 任务量以更陡的斜率上涨。产出胀了，验收没跟上。

这意味着：如果你只是把 agent 接进现有流程，结果不是效率提升，而是把瓶颈从写代码挪到了验证代码。原本卡在「没人写」，现在卡在「没人看得完」。

「用了 AI」和「成为 AI 原生」之间，有一条清晰的分界线。

判据：产物是否沉淀

一个容易操作的判据是：这家公司里，agent 犯过的错会不会变成组织资产？

如果每次 agent 出错，人都默默手改一遍，那么这家公司只是雇了一个更快的实习生——同样的错下周还会犯，经验只留在经手那个人的脑子里。反过来，如果每次出错都要求 agent 把教训写进规则文件或技能库，组织记忆就会变厚，同一类错误不会犯第三次。

运转单元的替换

传统公司靠会议和口头约定推进事情——信息在人的脑子里流动，靠人复述和记忆传递，靠层级做同步。AI 原生公司把这些换成显式的产物：需求是文件、规格是文件、计划是文件、验收结论是文件。因为只有文件，agent 和人才能读同一份东西。

这不是文档洁癖，而是必要条件：agent 无法参加你的晨会。

全文的结构性拱心石。理解这一章，后面六阶段就是自然推论。

这一章要解决的问题是：人和 agent 到底在什么接口上交接？

如果答案是「靠对话交接」，那这家公司没有 AI 原生——因为对话不可版本化、不可审计、不可追溯，也无法在被中断后恢复。所以答案是：交接点必须是被提交的产物。产物一提交，它就有了作者、时间、版本和上下文，人和 agent 都能在同一个东西上工作。

产物形式随阶段演进

从执行阶段起，产物不再是 markdown，而是代码变更和它的运行结果。但无论形式怎么变，它扮演的角色是同一个：跨全部六个阶段的唯一通用货币。

审计链是免费获得的

当每一环都有产物，审计就不再是一项额外工作。你不需要专门建一套台账，因为 commit 历史本身就是台账。这是这套结构最经济的地方。

每个阶段都用同一套模板描述：变化了什么 / 如何开始 / 实施步骤 / 治理考量 / 如何衡量。

采纳顺序不是线性的

这六个阶段描述的是一条完整的链，但不代表你必须从阶段一按顺序推到阶段六。各阶段之间的依赖强度不一样：有的必须先有前置产物，有的可以独立落地。

五要素模板

为了让每个阶段可执行而非可讨论，统一用五个问题描述一个 Play：

注意「如何衡量」不要用主观感受。「感觉顺畅多了」不是衡量。真正的衡量是：返工次数下降了多少、单次交付耗时缩短了多少、同类错误重复出现的频率变化。

把脑子里的需求，变成 agent 能读的东西。

变化了什么

以前需求停留在会议纪要、聊天记录和某个人脑子里；现在需求被写成一个文件，成为后续所有环节的唯一入口。agent 读它、人审它、出问题时回查它。

如何开始

下一次你要做任何一件超过半天工作量的事之前，先花二十分钟写一份意图文档。不要写长，一页以内。

# 意图：把候选人反馈从微信截图变成结构化回流

## 为什么做
当前客户反馈通过微信截图传递，人工录入到本地库，
平均延迟 2-3 天，且经常漏项。这直接影响下一轮推荐的
精准度——画像迭代建立在残缺数据上。

## 什么算做成
1. 客户能在网页上完成五维评分 + 批注并提交
2. 提交后 30 秒内到达内部通知渠道
3. 反馈自动落库为结构化记录，无需人工转录
4. 全流程人工介入不超过 3 处

## 明确不做
- 不做移动端 App（网页自适应即可）
- 不做客户账号体系（短链 + 一次性令牌足够）
- 不做历史反馈的可视化看板（下一阶段再说）

## 不可退让的边界
- 公网页面不得出现候选人姓名、电话、薪资原文
- 反馈数据只落本地，不写入任何第三方存储

## 相关背景
现有报告模板见 templates/，评分维度沿用五维设计。

实施步骤

1. 写「为什么」。用一段话说清现状的痛点，以及不做会怎样。这段决定了后续所有取舍的依据。
2. 写「什么算做成」。必须是可判定的句子。「体验更好」不可判定；「提交后 30 秒内到达通知渠道」可判定。
3. 写「明确不做」。这是最容易被跳过、但收益最大的一节。不划边界，agent 会自然地扩张范围。
4. 写「不可退让的边界」。合规、隐私、安全这类约束必须前置声明，不能等到验收时才发现踩线。
5. 存进仓库。放进版本控制，和代码一起。它是一份要长期存在的产物，不是一次性便签。

如何衡量

看两个数：返工率（因为理解偏差导致的重复劳动占全部工时的比例）和澄清轮次（一个新任务需要来回确认几轮才进入执行）。这两个数在一两个月内应该明显下降。如果没有下降，通常说明意图文档写成了任务清单，而不是意图陈述。

把意图翻译成可执行、可验证的结构化描述。

变化了什么

以前「需求」和「实现」之间靠人脑补全；现在中间多了一份显式的规格，把边界条件、失败处理、字段定义全部写下来，供 agent 执行和后续验证共用。

如何开始

把已有的意图文档交给 agent，让它起草规格。你的工作不是写，而是审——特别是审它没写的东西。

# 规格：<一句话概括>

## 输入
| 字段 | 类型 | 必填 | 约束 |
|---|---|---|---|
| 评分维度 | 整数 1-5 | 是 | 共 5 项，缺失即拒绝 |
| 批注 | 文本 | 否 | 最长 2000 字 |

## 输出
- 成功：{ ok: true, receivedAt: <时间戳> }
- 失败：{ ok: false, reason: <可读原因> }

## 边界条件
- 评分缺失或越界 → 拒绝，返回明确原因，不写入
- 重复提交 → 以最后一次为准，保留历史
- 网络中断 → 保留填写内容，允许重试

## 约束（不可退让）
- 不存储任何候选人身份字段
- 不在响应中回显原始输入

## 验证方式
- 逐条边界条件各有一个可复现的测试用例
- 至少一条失败路径被实际执行过

实施步骤

1. 让 agent 起草。输入是意图文档 + 相关上下文（现有代码、数据结构、约束）。
2. 补齐输入输出定义。字段名、类型、是否必填、长度和取值约束——这些是后期返工的高发区。
3. 逐条列出边界条件。异常输入、边界值、并发、中断、重复——要求 agent 穷举，而不是列两三条示意。
4. 标注验证方式。每条关键约束都要有一个对应的、可复现的检查手段。
5. 人确认后冻结。规格确认即冻结，后续变更走同一流程重新确认。

如何衡量

看执行阶段的意外中断次数。如果 agent 在实现过程中频繁停下来问「这种情况怎么办」，说明规格阶段漏了边界条件。中断次数应随规格质量提升而下降。

把规格拆成可独立验证的步骤，并标出依赖顺序。

变化了什么

以前「怎么落地」在执行的当下才临时决定；现在先有计划产物，执行过程只是按计划推进和记录偏差。

如何开始

把规格交给 agent 拆步骤。你的审核重点是粒度：每步是否能单独判定成功？如果不能，就还得继续拆。

# 计划：候选人反馈结构化回流

## 步骤与依赖
| # | 步骤 | 依赖 | 验证方式 | 闸口 |
|---|---|---|---|---|
| 1 | 定义反馈数据结构 | 无 | 字段清单经人确认 | 人 |
| 2 | 实现接收端点 | 1 | 边界用例全部通过 | — |
| 3 | 实现页面表单 | 1 | 桌面 + 移动端实测 | — |
| 4 | 打通通知链路 | 2,3 | 端到端实测收到 | — |
| 5 | 落库与去重 | 2 | 重复提交用例通过 | — |
| 6 | 上线前隐私扫描 | 4,5 | 扫描违规项为 0 | 人 |

## 可并行
- 步骤 2 与 3 可同时进行

## 明确不做
- 不做性能压测（预期并发极低）
- 不做多语言（当前无需求）

## 回滚方案
- 保留上一版部署包，异常时按包回滚
- 回滚后回读线上页面，不只看部署成功提示

实施步骤

1. 拆分步骤。每步粒度标准：能被单独验证成功或失败。做不到就继续拆。
2. 标注依赖。区分「必须先行」和「可并行」，这决定了实际的推进节奏。
3. 标注人工闸口。哪些步骤执行前必须等人拍板？写清楚，而不是默认让人盯全程。
4. 写回滚方案。任何会影响线上或不可逆的动作，必须提前写回退路径。
5. 人审后冻结。计划确认即作为执行基线，偏差要记录。

如何衡量

看计划外工作占比——实际执行中出现、但计划里没有的工作量比例。这个数偏高说明计划阶段对规格的拆解不够充分。

agent 干活，人盯闸口。

变化了什么

以前人是实现者，agent 是辅助；现在 agent 是实现者，人是审查者和闸口看守。这是六个阶段里角色反转最彻底的一环。

如何开始

给 agent 明确的任务边界（来自计划），然后只在你标注过闸口的地方介入。忍住不插手其他环节。

分级验收：爆炸半径决定门槛

这里有一个非常实用的判断框架：用爆炸半径决定你要投入多少审查。

如何衡量

看单位时间有效产出和闸口拦截率。前者体现 agent 放大的效果，后者体现人的注意力是否投在了对的地方。理想状态是产出大幅上升、被拦截的问题占比稳定在一个健康的水平——拦截率归零通常不是好消息，它可能意味着人已经不看。

把「做完了」和「做对了」变成两件不同的事。

变化了什么

以前验收是「看一眼感觉行就行」；现在验收是拿意图文档里的成功标准逐条对照，并留下书面结论。

如何开始

把 intent.md 打开，把「什么算做成」那几条抄出来，逐条打勾或打叉。不接受「基本达成」这种中间状态。

实施步骤

1. 逐条对照成功标准。每条给出明确的达成 / 未达成，不做模糊判定。
2. 验证边界条件。阶段二列的边界条件，至少实际跑一遍失败路径。
3. 检查「明确不做」有没有偷偷做。范围扩张是 agent 执行的常见副作用。
4. 核对不可退让的边界。隐私、合规、安全类约束逐项确认，不靠印象。
5. 写下结论。通过则记录，驳回则写清哪一条不达标、需要什么才能达标。

如何衡量

看验收一次通过率和上线后发现的问题数。前者反映前面几个阶段的质量；后者反映验收是否真的在做事。如果一次通过率很高但上线后问题很多，说明验收走了形式。

让这次的经验变成下一次的默认行为。这是复利的来源。

变化了什么

以前出了问题，经验留在当事人的记忆里；现在问题被写成事件记录，并转化成一条可执行的规则，下次 agent 执行时自动带上。

如何开始

出了问题不要急着修。先让 agent 写一份事件记录，然后问它一个问题：应该加一条什么规则，让这类事不再发生？

# 事件：<一句话描述>

## 发生了什么
<客观事实，不含推测>

## 影响范围
<受影响的产物 / 流程 / 客户>

## 根因
<追到机制层面，不停在「某人疏忽」>

## 发现的缺口
- 哪个阶段的哪个产物没有拦住它？
- 是产物缺失、标准不清，还是闸口被绕过？

## 规则补丁（需人确认）
| 补丁 | 加在哪里 | 拦截的问题类型 |
|---|---|---|
| ... | 规则文件 / 技能库 | ... |

## 验证
- 如何确认这条补丁真的生效？

实施步骤

1. 客观记录。先写事实，不写归因。混在一起会让根因分析失真。
2. 追根因到机制。「某人疏忽」不是根因，要问为什么流程允许这个疏忽造成后果。
3. 定位缺口。回到产物链，问是哪个环节本该拦住但没拦住：产物缺失、标准模糊，还是闸口形同虚设。
4. 写规则补丁。要求具体到「加在哪、拦什么」。模糊的改进承诺不算补丁。
5. 人工确认后合入。规则文件的修改是人的判断权，不能由 agent 自行决定。
6. 验证补丁生效。下次同类场景出现时，确认它真的被拦住了。

如何衡量

最重要的一项指标：同类问题的重复发生率。如果同一类事件三个月内出现两次，说明第一次的闭环没做实。第二项是规则库的健康度——条目是否还在被引用，有没有明显冲突或过时条款。

如果你今天只带走一个判断，带走这个。

AI 原生转型最难的部分不是技术接入，而是重新分配判断权。谁能拍板、谁只负责执行、什么情况下必须停下来等人——这三件事定义了一家公司的形态，而不是它用了什么模型。

这套手册给出的结构可以简化成三句话：