我为什么做了 Evidence Writer：第一个开源软件，也是我第一次真正用 AI 做成一个工具

1. 为什么要做它：我越来越不信任“看起来很像事实”的句子

AI 写作最麻烦的地方，不是它偶尔写错一个数字。真正危险的是，它很擅长把不同性质的东西揉成一种语气。
一个来源明确的事实，一条暂时出现的趋势，一个作者自己的判断，一个模型顺手补出来的推断，
最后可能都被写成同样平滑、同样肯定的句子。

对普通闲聊，这种问题未必严重。对研究文章、政策解读、行业分析、医学科普、企业内容，问题完全不同。
一句话写得顺不顺，和它有没有资格被写出来，是两件事。很多时候，模型不是“不知道”，而是“知道得太多”，
又没有人告诉它这一次到底有权使用哪一部分。

我后来把这个问题概括成一句话：模型知道很多，但这一次，它到底有权说什么？

这句话最后成了 Evidence Writer 的真正起点。它表面上是一个写作工具，底层更像一个
“证据权限控制型生成器”。

2. 它不是突然出现的：从一套内部写作 Skill 长出来

Evidence Writer 并不是先有代码，后找用途。顺序恰好相反。我先有了一套长期反复使用的内容生产流程：
选题研究、资料整理、证据审计、作者意图、写作能力选择、成稿、终审。最初这些东西以自定义 Skill、
长 Prompt、规则文档和人工检查的方式存在。

Google Drive 里保留下来的旧版本能看到这条演化链：Research、Evidence Audit、Writer Handoff、
Author Intent、Capability Adapter、Writer、Final Review。后来我意识到，如果它永远只是 Prompt，
那么很多关键规则仍然只能靠模型“理解”和“自觉”执行。

所以我做了一个重要转向：不再把长 Prompt 当作最终产品，而是把规则重新拆成机器可以验证的数据结构和软件合同。
这一步，是从“写作工作流”走向“软件”的真正分界线。

过去的“名家能力研究”也没有直接塞进运行时。它被拆成了可迁移的能力，例如“减少解释”“把判断放回材料”
“延迟命名情绪”“克制结尾”“保留开放问题”等。作者名、作品名、模仿指令和受版权保护的长文本，
不进入生产运行时。

3. 它真正解决的，不是“会不会写”，而是“能不能越界”

普通 AI 写作系统通常是：资料交给模型，模型输出文章。Evidence Writer 中间多了一层显式权限。
我把材料里的信息分成五类：

这个分类看起来简单，但它改变了整个写作过程。模型不再拿到一堆“都可以自由发挥”的材料，而是拿到一份带权限的证据包。
这也是为什么我越来越不愿意把它叫作一个普通“AI 写作工具”。

4. 从 Prompt 到 Contract：我真正想固定下来的东西

软件里最关键的不是一句神奇提示词。相反，我后来尽量减少“相信提示词会一直有效”这种幻想。
重要信息被放进显式合同，阶段之间通过 artifact 传递，关键对象有 schema、版本和摘要。

ResearchPackage 负责定义材料和证据；WriterHandoff 是审计后的授权结果；AuthorIntent 只说明作者为什么写、
站在哪里、不能写成什么；Capability Selection 只决定采用哪些写作机制；Final Review 则不是单纯“润色”，
而是重新检查成稿有没有把外部事实、作者判断和推测混在一起。

这个架构还有一个很重要的原则：fail closed。上游如果失败，下游不应该假装继续成功。
输入不合法、artifact 被篡改、证据链断裂、Provider 失败，都应该留下明确状态，而不是悄悄产出一篇貌似完整的文章。

5. 我为什么坚持做五篇真实文章 E2E，而不是只看单元测试

软件能启动，和软件真的有用，是两回事。到后期，我把测试主线压缩成五篇真实文章。
这五篇并不是为了凑数量，而是逐级增加难度。

A3 给我的印象很深。像“4A”这种数字很容易被脱离体系单独理解，甚至直接被写成“某个人有多少癌症概率”。
最终文章必须保留：这是一个分类体系中的群体风险分层语言，不等于个体诊断。

A4 更接近我真正想验证的东西。模型在草稿里写出过类似“这些指标都朝着同一方向、以同一速度变化”的判断，
但材料并没有授权它这么说。Final Review 最后把这句删掉了。这一刻我第一次比较直观地看到：
它不是在“改文风”，而是在执行证据权限。

除了五篇真实文章测试，发布候选最终还跑了 63 项自动化回归测试，全部通过。

6. 从“能跑”到“真正开源”，中间还有很长一段路

这次我也第一次完整经历了一个软件从开发到公开发布的过程。以前我会把“代码能跑”理解成接近完成，
这一次才真正意识到，软件交付最后一公里有很多完全不同的工作。

我们先区分了 production、staging、GitHub 远程，避免把本地状态误认为远程状态；确认真正通过 A3/A4 的 runtime
匹配的是 clean repo，而不是一套尚未验证的 source-stage 修改。之后补 MIT License、Acknowledgements，
检查当前树和全部远程分支历史中是否包含密钥、PAT、私钥、`.env` 等敏感内容。

公开前还经历了一个很典型的错误：第一次历史扫描只覆盖了 main，但 GitHub 实际还有另外五个远程分支。
新证据出现后，旧结论被立即撤销，重新抓取六个远程分支并扫描全部可达历史，最后 76 个唯一 blob 没有发现敏感信息。

最终仓库从 Private 改成 Public，创建 MIT License，打上 annotated tag `v0.1.0`，
再基于这个 tag 创建 GitHub Release。这个过程让我第一次把“代码、版本、许可、公开历史、Release”这些过去很抽象的东西，
真正连成了一条完整链。

7. 这个软件到底有没有价值？我的答案是不回避两面

最强的反驳很简单：既然 ChatGPT、Claude、Gemini 已经可以搜索、引用、写作，为什么还需要 Evidence Writer？
如果这个软件只是“把 Prompt 写得更复杂”，那它的价值很有限，而且迟早会被更强的基础模型吃掉。

但 Evidence Writer 现在已经不只是 Prompt。它把边界放在 Contract、Schema、Policy、Artifact、Digest、
fail-closed 和 Final Review 上。也就是说，它不依赖“模型应该会听话”，而是在模型外面增加一层可验证的约束。

这件事在普通写作里也许显得重，但在研究报告、政策解读、企业白皮书、行业分析、专业媒体、咨询交付等场景里，
一次错误归因、一次把推测写成事实、一次把旧政策写成现行规则，成本会明显高于多花几分钟。

所以我现在更愿意把它看成一种“证据治理型生成基础设施”。它目前已经证明了工程价值和方法论价值，
但还没有证明商业价值。

这不是一句谦虚话，而是必须保留的边界。开源、测试通过、架构漂亮，都不能自动推出“有人愿意付钱”。
真正的商业证明必须来自使用者：有人因为它节省了时间、减少了错误、提高了交付稳定性，或者愿意直接为结果付费。

8. 如果要产生现金流，我更愿意先卖结果，而不是先卖软件

Evidence Writer 现在并不适合直接面向普通用户做成一个“一键写作 SaaS”。它仍然要求结构化输入，
也没有 Research Search、RAG、数据库和 Web UI。为了迎合大众而急着把这些功能都补上，很容易重新陷入无穷开发。

更现实的路径，是先把它当作后台生产系统。客户不需要理解 ResearchPackage，也不需要自己操作软件。
他只需要给出资料和问题，最后拿到一份有来源链、有证据边界、有作者判断、经过终审的正式成品。

如果这种服务真的有人反复购买，再把稳定出现的流程做成 Team Tool、API 或 SaaS。这样软件不是凭空寻找市场，
而是从已经发生的需求中长出来。

9. 这是“AI 做的软件”吗？是，但不能把所有成果都算给 AI

这个项目大量依赖了 AI。代码、测试、错误分析、文档、命令、GitHub 操作、架构讨论，都有 AI 参与。
如果没有今天的大模型，一个没有传统软件工程背景的人，很难用这样的速度走完这条链。

但 AI 并没有替我决定“为什么做”。它也没有自动知道哪些失败值得修，哪些审计已经开始膨胀，
哪个功能应该放弃，哪一条证据边界才是产品真正的核心。

这个过程中，我最重要的工作并不是敲代码，而是不断做判断：目标是什么，哪些步骤直接推进目标，
哪些只是“看起来更严谨”的旁支；什么应该进入 runtime，什么必须留在 Reference Library；
什么是软件能力，什么只是写作偏好；什么时候应该继续，什么时候应该停止。

AI 极大降低了“把想法变成软件”的技术门槛，但它没有取消产品判断、边界设计和验收责任。

所以我愿意把 Evidence Writer 称为“真正意义上利用 AI 完成的第一个工具软件”，
但我也愿意明确区分：AI 是强大的执行和推理伙伴，产品方向、约束、最终验收仍然需要人负责。

10. 我学到的最大一课，甚至不是代码，而是“审计也会失控”

这个项目最折磨人的阶段，并不是模型写不出代码，而是验证会自己膨胀。发现一个疑点，就多加一个 gate；
为了证明 gate，又去追历史脚本、fingerprint、旧日志；很快测试软件变成了“审计我们如何审计软件”。

后来我给流程加了一条很硬的规则：任何步骤都必须回答，它是否直接推进当前主线。
A3、A4 通过后，文章测试立即关闭；非阻塞问题进入 backlog。每三步做一次范围审计，但范围审计不能再衍生新的审计任务。

这条经验比很多具体命令更重要。AI 特别擅长继续解决“眼前最近的问题”，也特别容易把局部严谨推到全局失控。
如果顶层目标不被冻结，模型越聪明，反而越可能把时间消耗在边际价值越来越低的验证上。

另一个教训是：本地、staging、production、GitHub 远程必须分开验证。一次本地测试成功不等于远程已经交付；
一个 commit 存在不等于 Release 已经发布；仓库 Public 也不等于 tag 和 Release 指向了正确的 commit。
真正完成，是最终产物确实存在于权威目标位置。

11. 下一步：不急着继续加功能，先验证有没有真实需求

v0.1.0 已经发布，但我现在反而不想马上给它加二十个功能。一个开源项目很容易在“还能再完善一点”的理由下继续膨胀，
最后变成一个设计越来越漂亮、却没有真实用户的工程。

接下来最重要的不是继续证明我能开发，而是找真实问题：有没有人真的因为 AI 越过证据边界而付出成本？
有没有团队需要一份“事实、信号、假设、限制、禁止项”分得更清楚的内容交付？
有没有人愿意为这种稳定性付哪怕一小笔钱？

如果答案是否定的，Evidence Writer 也不会完全失去意义。它仍然是我自己的内容生产基础设施，
也是我第一次把长期思考、写作经验、AI 使用经验和工程方法真正沉淀成一个公开的软件。

如果答案是肯定的，它才会从“第一个开源作品”，开始变成一个真正的产品。

12. 项目事实｜截至 2026 年 9 月 19 日