业务目标与今日推进
业务目标：把团队每天产生的文档、证据和 review 变成可复用知识资产、可执行下一步、可避免反模式，并服务产品交付、研发协作、客户项目推进和团队管理透明度。
今日判断：朝目标前进不是只新增文件，而是把“市场研究怎么做”“退款问题怎么留证”“团队问答怎么沉淀”“仓库变更怎么提交”都转成了规则和证据。
84输出前扫描到今天变更的候选文件
12数字业务商业验证目录文件数
7 组H5 本人订餐重复组，验证后为 0
3 个今天可直接复用的新/强化 skill 方向
结论性复盘
| 今天结论性做成的事 | 为什么重要 | 数据或证据支撑 | 对业务目标的贡献 | 还差什么 |
|---|---|---|---|---|
| 数字业务市场研究从泛“智慧食堂报告”纠偏为“第二增长曲线商业化验证”。 | 避免只讲行业和功能，回到先赢哪里、靠什么产品包赢、能否回款和复用。 | 12 个文件；9 张 CSV；8 个细分市场评分；23 行证据台账；10 行验证 backlog。 | 把战略讨论转成证据台账、市场优先级和 90 天验证门禁。 | 补毛利、回款、验收、交付人天、续费和复用率。 |
| 旧版 2026-06-15 市场报告被降级为草稿。 | 防止团队继续引用被用户纠偏的旧结论。 | 旧 MD、旧 HTML、旧竞品文档均新增纠偏提示。 | 把被否定做法转成 stop rule。 | 后续报告默认加载市场研究验证 skill。 |
| H5 本人订餐重复数据完成退款处理和验证。 | 直接处理重复有效订单，留下可复查口径。 | 7 组重复；处理 14 单；10 单退款；退款总额 200.00；验证后重复组为 0。 | 把数据修复转成可复用排查证据。 | 确认环境边界；生产动作仍需人工审批。 |
| H5 订餐取消退款流水口径修复复盘完成。 | 解决退款详情单号显示异常和空值报错。 | 余额流水回填 8 条，补贴流水回填 24 条；PHP lint、eslint、diff check 通过。 | 给研发和测试明确新旧数据兼容规则。 | 真实测试环境继续回归。 |
| 团队线程记录和自动提交规则落地。 | 以后团队问答和仓库变更不只停留在聊天里。 | 新增 skill、eval、thread record、任务索引；task index 和 skill validate 通过。 | 把团队协作 SOP 转成可执行能力。 | 后续真实线程持续执行，避免形式化。 |
今天新增/更新了什么
- 数字业务商业验证：正式 HTML/Markdown、证据台账、细分评分、用户画像、旅程、竞品替代、TAM/SAM/SOM 和验证 backlog。
- 市场研究方法：新增 `digital-business-market-research-validation`，旧市场报告被标为草稿。
- 国信 / H5 订餐：重复订单处理、退款流水回填、新数据口径和验证结果已留档。
- 接口契约：SSO ticket 空 `data` 统一为 `{}`，bookingVerify 继续补现场消费扣款口径。
- 团队协作：线程 Markdown 记录、自动拉取/验证后提交、Git 边界和任务索引更新。
- 手册原型：后台端场景化介绍、操作手册中心、智能排菜系统原型有更新痕迹。
你现在应该看什么
| 文件或页面 | 为什么值得看 |
|---|---|
| 数字业务商业化验证 HTML | 看 2026 年先打哪里、为什么、证据够不够、90 天怎么验证。 |
| source-evidence.csv | 看每个商业判断背后的证据等级。 |
| 退款流水修复复盘 | 研发/测试看根因、回填、兼容和验证结果。 |
| 团队线程 Markdown 记录规则 | 以后每次可复用问答怎么沉淀。 |
| 操作手册中心 | 快速进入当前手册、视频和场景化介绍。 |
下一步怎么执行
| 事项 | 建议负责人或角色 | 下一步动作 | 截止或触发条件 | 证据路径 |
|---|---|---|---|---|
| 确认数字业务 P0 主战场 | Jack / 业务负责人 | Review 商业验证 HTML，确认是否锁定政企/机关/央国企/大型企业职工食堂。 | 下次产品/经营讨论前 | kangbite-digital-business-commercial-validation.html |
| 补项目经济性证据 | 财务 + 销售 + 交付 | 补 11 个收入样本的合同、成本、毛利、回款、验收、交付人天。 | 第 1 周 | validation-backlog.csv |
| 国信退款链路回归 | 研发 + 测试 | 验证个人余额、补贴账户、部门账户、历史兼容和退款单号展示。 | 测试环境可用或 MR 合入时 | meal-booking-refund-log-normalization-20260617 |
| SSO ticket 契约确认 | 接口负责人 + 前端/第三方 | 确认失败时 `data={}` 是否进入正式接口文档。 | 下次接口文档同步前 | sso-ticket-data-shape-20260617.md |
| 团队线程记录试运行 | 未来所有 zhctprompt Agent / 同事 | 下一个实质问答按线程生成 Markdown。 | 下一条可复用问答出现时 | team-thread-markdown-record/SKILL.md |
可以复用的好做法
- 先写调研合同，再写市场研究。
- 每个战略结论都带证据等级、反方观点和验证缺口。
- 被纠偏的旧文档要显式降级，不要删除也不要继续当正式结论。
- 生产或客户相关问题处理后，要留下处理口径、影响范围、数据结果和验证命令。
- 团队规则沉淀要有 skill、eval、thread record、任务索引和验证结果。
不要踩的坑
- 不要把“智慧食堂行业很大”写成“康比特第二增长曲线成立”。
- 不要把 D 级 TAM/SAM/SOM 假设写成对外承诺。
- 不要继续引用已被纠偏的旧市场报告作为正式结论。
- 不要把自动提交理解成自动 push、MR、强推、stash、reset 或覆盖同事改动。
- 不要把原始线程、敏感 payload 或被否定草稿直接当训练数据。
待确认问题
- 数字业务 P0 主战场是否正式锁定为政企/机关/央国企/大型企业职工食堂？
- 11 个收入样本中，哪些已有合同、验收、回款、毛利和售后成本证据？
- 体育系统/训练基地是品牌样板，还是 2026 年收入目标？
- 校园餐食安营养监管是否有明确付费方、资金流和运维责任？
- H5 订餐退款修复是否已在测试环境全链路回归？
- 操作手册中心和后台端介绍是否可给同事或客户看？