PoC 最容易犯的错，是把它当成一个缩小版项目来管：先调研、再设计、然后开发、最后演示。问题是第 12 天才第一次跑起来，第 13 天发现数据对不上，第 14 天只能演 PPT。
更稳的做法是反过来排：先定义“演示那一刻长什么样”，再从那天倒推今天该干什么。
D0：先写一句验收话
不是需求文档，是一句话。必须包含四件事：谁、在什么设备上、做什么动作、达到什么结果算通过。
第 14 天，[业务同事] 在他自己的电脑上，
把一份新合同拖进页面，30 秒内看到 5 个关键条款和原文位置；
随机抽 10 份，至少 8 份的条款抽取正确。
这句话写不出来，说明需求还没到能做 PoC 的程度。这时候最该做的不是开工，而是拉上提需求的人一起把这句写完。写的过程会暴露三个分歧：验收人是谁、什么算“正确”、失败的边界在哪。
D1–D2：切一条最短闭环
把场景切到只剩一条路径。登录砍掉，权限砍掉，多角色砍掉，历史数据迁移砍掉。只保留“输入 → 处理 → 输出”这一条线。
判断砍得够不够狠，有个标准：能不能在一个下午手动画出完整流程，并且每步都知道输入输出是什么。如果画不出来，说明还有一个环节没想清楚。
这两天的产出不是代码，是一页纸：流程图、验收句、明确不做的清单。不做的清单要发给对方确认，避免第 10 天有人问“怎么没有审批流”。
D3–D4：先做数据体检
AI 项目的失败，八成死在数据上，而不是模型上。这两天只做三件事：
- 拿真实样本。不要用对方整理的“样例包”，要原始文件。30–100 份就够，覆盖不同类型的边界情况。
- 建金标准。人工标出 20 份的正确答案，后面所有效果讨论都对着它，而不是对着感觉。
- 做体检。缺失、格式、重复、敏感信息、权限边界——尤其是最后一项：哪些数据根本不能出内网。
如果数据体检就发现做不了（比如关键数据在纸质档案里、或者不允许上传），这时候停下来是好事，比第 12 天发现好得多。
D5–D7：打通最笨的链路
这三天的目标只有一个：端到端跑通一次，哪怕效果很差。
先用最笨的方法：脚本读文件、调模型、把结果写进表格或一个简单页面。不要在这时候优化提示词，不要设计抽象层，不要引入框架。链路没通之前的所有优化都是猜测。
跑通的标准是：换一份新文件，不用改代码，能从头走到尾。这一步做扎实，后面调优就是局部修改；做不扎实，每天都会在“到底哪一环错了”上耗掉半天。
D8–D10：按错误类型调，不按感觉调
把失败样本摊开，分四类：
| 错误类型 | 典型表现 | 先动哪里 |
|---|---|---|
| 没找到 | 答案在库里，但没检索出来 | 切片、检索方式、同义词 |
| 找错了 | 检索到相似但无关的内容 | 元数据过滤、重排 |
| 答偏了 | 材料对，但生成的结论不对 | 提示结构、上下文组织 |
| 格式不符 | 内容对，但不是要的结构 | 输出约束、解析层 |
每类错误的修法完全不同。混在一起看，就会陷入“改了提示词，检索问题没解决，整体看起来还是不行”的循环。
这三天还要做一件事：把“不知道”设计进去。检索不到时明确说找不到，并给出处，比编一个像样的答案强得多——尤其在制度、合同、医疗这类场景里。
D11–D12：准备演示，包括失败样本
演示不是把最好的结果放一遍。真正让人信服的是三件事：
- 现场换一份新文件，证明不是预置数据。
- 展示一个失败案例，说明你知道它为什么失败、下一步怎么改。
- 录一段屏作为兜底，防止现场网络或环境出问题。
还有一个容易忽略的点：演示环境。用自己的电脑还是对方的？能不能连外网？模型调用走哪条线？这些在 D11 就要确认，不要留到当天早上。
D13–D14：复盘，留下三样东西
PoC 结束不是“演示成功”或“演示失败”，而是回答一个问题：值不值得进入下一阶段，凭什么判断。无论结论是什么，都留下三样：
- 评估集：那 20 份金标准加上问题清单，下一阶段直接复用。
- 部署说明：环境、依赖、数据从哪来、怎么更新。让别人能跑起来。
- 下一步清单：按“影响大、成本低”排序的 5 件事，写清楚每件的前置条件。
五个常见坑
- 需求在演示前一周变。对策：验收句在 D0 定完就冻结，变更只能进“下一阶段清单”。
- 数据不能出内网。对策：D0 就问清楚，必要时用本地部署或脱敏样本。
- 把 demo 当上线。对策：演示页上明确写“原型”，并在复盘里列出上生产缺的东西：权限、日志、监控、失败兜底。
- 没有验收人。对策：D0 就指定一个人，并且让他在 D11 参加彩排。
- 只调模型不管工程。对策：每天留半小时看日志和失败样本，工程问题通常比模型问题多。
下一篇写知识库项目里最费时间的部分：RAG 的五个取舍。