夜雨聆风DECISION LEDGER · AI CODING
AI写得越快，产品规则越需要留下来路
开发一个产品时，有些决定很容易被记住，比如选什么技术栈、卖多少钱、先做哪类用户。另一些决定则安静得多：免费账户最多保存多少条记录，普通成员能否邀请新人，删除数据后保留几天，失败的支付要重试几次。
这些小决定数量很多，分散在不同阶段。它们被写进代码之后，很快便失去原来的面貌。几个月后重新看到一条判断，你可能只觉得它有些古怪，却想不起当初为什么坚持这样写。
AI 恰好很擅长处理古怪的代码。它会建议合并重复逻辑、删除多余分支、统一权限判断，让整个项目显得更整洁。倘若那段“多余逻辑”背后藏着业务承诺，清理完成的同时，产品规则也被一并清理了。
代码可以被重构，产品决定不能失去来路。
01
决策账本记录产品的来路
所谓产品决策账本，不需要复杂的软件，也不必每天维护。它更像一本放在代码旁边的航海日志，专门记录那些会影响后续开发路线的决定。
一条合格的记录，至少要回答几个问题：当时遇到了什么情况，最后选择了什么方案，为什么这样选，还有哪些方案被放弃。它最好写明影响范围，以及什么条件出现时可以重新讨论。
DECISION RECORD · 示例
免费用户最多创建三个项目。
这个限制用于控制存储和模型调用成本，同时保留完整的试用体验。项目数量达到上限后，可以继续查看和导出已有内容，但不能创建新项目。若免费用户的付费转化率连续两个月低于目标，再重新评估上限。
这段话只有几十个字，却比代码中的 if project_count >= 3 多保存了很多东西。AI 能看到数字，也能看到数字背后的商业考虑；它可以修改页面提示，却不会因为“优化体验”就擅自把限制改成五个。
记录发生变化时，也别直接覆盖旧内容。旧决定保留下来，标明已被哪一条新决定取代。这样做看似有些笨，却能避免一种很常见的混乱：代码遵循新规则，文档仍在描述旧规则，AI 随机读到其中一份，便把错误继续传下去。
02
权限、金钱和数据要写得更清楚
并非所有决定都值得登记。按钮放左边还是右边、变量怎样命名、页面用哪种留白，可以交给实现者判断。权限、计费、数据和外部服务则应受到更严格的照看，因为这些地方一旦漂移，通常会直接影响用户权益。
权限 PERMISSION
权限最好做成一张简单的矩阵。Owner、Member、Guest 分别能查看、创建、修改、删除和导出哪些内容，一眼就能看明白。没有明确授权的操作默认禁止，AI 也不得为了减少代码分支而扩大权限。
计费 BILLING
计费规则需要写明金额单位、扣费时点、退款条件和套餐降级后的处理方式。许多支付问题并非计算错误，而是产品没有把“什么时候算完成”“失败后怎么办”说清楚。AI 只好根据常见做法补齐，恰好补成你想法的概率并不可靠。
数据 DATA
数据规则则要回答：哪些信息可以发给第三方，哪些必须保存在自己的系统里，账户删除后保留多久，用户是否能够导出。接入一个新的分析工具，对开发者而言可能只是添加 SDK，对用户而言却可能改变数据流向。这些规则可以放进一份 CONSTRAINTS.md。措辞越直接越好，多使用“必须”“不得”和“只有在……之后才可以”。含糊的愿景适合讨论，交给 AI 执行的边界需要足够坚硬。
03
写代码前先交代假设
很多人使用 AI 时，会在需求后面加一句“直接实现”。这句话省去了几轮沟通，也让 AI 隐藏的假设直接进入代码。
涉及账户、支付、权限或数据的功能，可以多加一个短步骤：要求 AI 在动手前写出它对需求的理解，并列出准备自行决定的部分。提示词不必复杂：
PROMPT · 开发前
请先说明本次改动会影响哪些产品规则，并列出需求中没有明确说明、需要你自行假设的内容。凡是涉及权限、计费、数据流向、外部服务和架构变化的假设，等我确认后再实施。
这一轮通常只花几分钟，却很容易发现方向偏差。AI 可能会告诉你，它准备允许所有成员发起邀请，默认删除账户后立即清空数据，或者用新的第三方服务处理邮件。它把想法写出来时，你会立刻知道哪里需要踩刹车。
完成代码后，还可以换一个会话进行审查，并让它读取产品决策账本。审查问题也要有所调整，别只问“有没有 Bug”，可以问：
PROMPT · 完成后
这次改动是否引入了需求之外的产品规则？是否改变权限、计费、数据边界或既有架构？请为每项判断提供对应的代码位置和决策依据。
Prelint 采用的也是相近思路：让审查器读取产品规格、ADR 和历史决定，再检查代码是否发生漂移。它提供了一套自动化产品，但 OPC 完全可以先用几份文档和一个独立审查会话完成简化版流程。
04
发布前，检查那些悄无声息的变化
OPC 的发布检查表不宜太长。十个问题已经足够，其中最重要的几项是：
01
有没有增加需求中未提及的功能？
02
有没有改变角色权限和数据可见范围？
03
有没有调整价格、额度或扣费时点？
04
有没有引入新的依赖和外部服务？
05
有没有绕开既有的服务层、事件流与审计机制？
06
如果理解有误，是否能够安全回滚？
这份检查表的价值不在于阻止所有错误。它让那些容易被包装成实现细节的决定重新浮到水面，等待一次明确确认。产品可以改变，规则当然也可以推翻，只要变化留下了来路，责任仍由产品的主人承担。
AI 把代码生产压缩得很快，一天可以完成几个功能，也可以同时打开几个方向。产品决策却仍需要慢一点，因为它们会进入用户习惯、合同承诺和数据结构，日后很难像代码一样随手重写。
给自己留一份产品决策账本，听上去没有自动生成整套功能那样令人兴奋。但当你在半年后打开项目，面对几十次 AI 修改留下的代码，它会帮你回答一个十分朴素的问题：
这里为什么会是这个样子？
关注 OPCBOOK
让更多优秀 OPC 被看见、被链接
如果你是正在用 AI Agent 提升交付能力的 OPC，或你所在的企业正在寻找更年轻、更敏捷、更 AI 原生的外部协作力量，欢迎关注 OPCBOOK。我们将持续连接真实企业需求、产业场景与优秀 OPC，让更多合作机会真正发生。
长按识别二维码，关注 OPCBOOK
关于 OPCBOOK
OPCBOOK 是面向 AI 时代 OPC 的 Agent 原生连接与任务平台。我们希望帮助个体沉淀能力资产、项目经验与协作信用，也帮助企业和生态伙伴发现可信个体、发起任务协作、推进真实交付。
在 OPCBOOK 看来，AI Agent 不只是工具，而是让更多个体拥有“像组织一样运转”的能力。连接、判断、协作和交付，都可以因此变得更高效、更可信。
资料依据
01Prelint Product Hunt 发布页
02Prelint 工作机制
03Prelint AI Code Pulse
04GitHub：Spec-driven development with AI
05Martin Fowler：Architecture Decision Record