OPC 经营与接单交付

一套把"怎么不出事"变成肌肉记忆的操作流程。核心不是帮你写代码，而是帮你在正确的时点做正确的动作、留下正确的书面痕迹。

五条底层原则

1. 风险在决定接单那一刻就已确定。烂客户无法靠流程救回来，所以先筛客户，再谈方案。
2. 定金不到账 = 项目没开始。不做前置投入，不给任何代码。
3. 一切以书面为准。需求、变更、验收都必须有可追溯的文字记录；口头承诺不算。
4. 付款与交付交替进行。让双方跑路成本都很高，是唯一稳定的约束。
5. 边界先定死：范围、期限、售后。开一个口子，就等于变成免费 on-call。

快速路由表

先判断用户处在哪个阶段，再只加载需要的资源，不要一次性推销全流程。

接单交付主流程

按 B1→B11 推进。每一步都遵循同一套输出格式：当前阶段判断 → 必做动作 → 产出物 → 本条红线。

B1 线索筛选

问三个问题并记录答案：预算具体数字、为什么是这个时间点、想达到什么可量化效果。三个答案里有两个含糊，直接给"条件接"或"婉拒"。

同时运行 python scripts/risk_scan.py 扫描聊天记录原文，检查是否命中红线信号。命中任意一条既定红线（先做后谈钱、拒绝书面沟通、纯比价、换过三个以上外包、周末深夜发需求、说不清目的、"这个很简单吧"）→ 明确建议婉拒，并给出婉拒话术。

B2 报价与分期

默认 50% / 30% / 20%（定金 / 中期 / 尾款）。金额大或首次合作，可用 30% 定金起、中期 40%、尾款 30%。定金下限 30%，不接受先做后付。

用 scripts/deal_calc.py split 算清每一笔的绝对金额——绝不让用户自己心算。

B3 合同

逐条确认 8 项必备条款。特别检查两处最常被漏掉的：逾期不确认视为验收通过、中途叫停的结算方式。合同文本只作结构与条款清单参考，明确提示用户找律师过一遍。

B4 定金到账即启动

没到账不排期、不建仓库、不做需求。对"先做着，钱马上到"的回应：合同已签、账号已就绪，定金到账当天开工。

B5 需求确认（比写代码更重要）

输出三件套：功能列表（每个功能的页面/接口与输入输出）、数据流（核心流程编号列表）、边界条件（超出什么算变更）。发客户并要求邮件回复确认。这封确认邮件是后续拒绝范围蔓延的唯一硬武器。

B6 周进度同步

每周五固定一封，四段：本周完成 / 下周计划 / 阻塞项（需甲方配合）/ 整体进度百分比。作用是造一条可追溯的沟通链，而不是礼节性汇报。

B7 中期交付 + 中期款（进度 60%~70%）

交付可运行演示（部署在测试环境，不给源码）、已完成模块 vs 计划对比、中期验收确认单。客户确认后收第二笔。

B8 交付包四件套

1. 验收清单：一行一个需求点，带"通过 / 修改 / 不适用"和签字栏。
2. 部署文档：环境要求、依赖版本、配置说明、部署命令、数据库脚本。验收标准是"没参与项目的初级开发照着能部署成功"。
3. 操作手册：截图 + 无技术术语的白话步骤。
4. 结项报告：做了什么、用了什么技术、已知问题、维护建议（同时是 portfolio 素材）。

B9 验收

书面约定验收期限（7 个工作日），逾期未反馈视为通过。流程：提交交付包 → 客户逐项打勾 → 签验收确认书 → 付尾款 → 移交源码/备份/权限。

B10 尾款

源码在尾款之后交付；部署版可先给，源代码版不给。客户压价时拿验收清单对账："这些功能当时已逐项确认通过，新需求可另签维护合同。"算好止损线：必要时收 85%~90% 了结并永久拉黑，别为 10% 拖成长期消耗。

B11 售后边界

7 个自然日免费修 bug，仅限需求文档范围内的功能缺陷；不含新功能、变更、第三方服务问题。之后转独立维护合同，按季度签、不做月付。

OPC 经营层

当用户不是在做单个项目，而是在设计"一个人怎么持续赚钱"时，切到这一层：

• A0 选方向：三个低门槛切入口——AI SaaS 小工具（垂直场景，三天出 MVP，收月费）、AI 内容工厂（垂直领域内容产能工业化，内容→流量→转化）、AI 咨询诊断（客户提需求 → AI 出分析 → 你审阅打磨交付）。选择判据看三件事：手上有没有该垂直领域的现成经验、能不能在 3 天内做出可演示的最小版本、有没有现成的信任资产。
• A1 收入结构：项目制现金流打底 + 维护订阅做稳定盘子 + 产品化（SaaS/模板/课程）做杠杆。别只卖时间。
• A2 复盘：项目亏损时按阶段定位——筛选、报价、范围、验收、尾款，指出具体是哪一环漏了，而不是笼统说"下次注意"。

细节见 references/opc-playbook.md。

使用模板的规则

1. 从 assets/ 读取对应模板，把 {{占位符}} 全部替换为项目真实信息；有占位没填就问用户，不要留空。
2. 输出到用户当前工作目录，文件名带项目名与日期，例如 验收清单-客户A-20261102.md。
3. 需要 Word 交付时走 workbuddy-docx 技能；需要表格化（验收清单、报价明细）时走 workbuddy-sheet-generation。
4. 模板是结构与清单，不是法务意见。涉及合同、税务、知识产权归属时，明确提醒用户请专业人士复核。

脚本

# 分期金额拆分（默认 50/30/20）
python scripts/deal_calc.py split --total 16000
python scripts/deal_calc.py split --total 16000 --plan 30/40/30

# 中途叫停按比例结算：已完成进度 60%，尚未摊销前期成本 2000，已收 4800
python scripts/deal_calc.py settle --total 16000 --progress 60 --cost 2000 --received 4800

# 维护报价区间（项目总价的 5%~10%/月，按季度计）
python scripts/deal_calc.py maintain --total 16000

# 客户沟通记录红线扫描
python scripts/risk_scan.py --file chat.txt
echo "你先做着，做完了我们再谈钱" | python scripts/risk_scan.py

两个脚本都是纯标准库、无网络依赖，可直接在 Windows / macOS 运行。

交付前自检

在告诉用户"可以交付了"之前，逐条确认：

• 需求文档有客户书面确认吗？
• 验收清单每一条都能对应到需求文档里的功能点吗？
• 验收期限、逾期视为通过，写进书面约定了吗？
• 交付包里四件套齐了吗（清单/部署/手册/报告）？
• 部署文档普通人照着能跑通吗？
• 操作手册里有没有残留技术黑话？
• 尾款未到账时，交付的是部署版而非源码版吗？
• 7 天修复期的起止日期和范围说清了吗？
• 已知问题如实写在结项报告里了吗？
• 所有承诺都落在文字上，没有只存在于通话里的约定吗？

语气与边界

直接、可执行、不绕弯。用户问"要不要接"就给明确结论和理由，不要罗列一堆"取决于"。但不要在用户没问的时候把整套 SOP 倒出来——只输出当前阶段需要的那几步。