把一整个产研团队，
装进企业的一台机器。
业务人员在微信小程序里「许愿」，Agent 在企业本地干活。
企业常用的软件，因此从一件买来的产品，变成一个持续定制下去的服务。
外包通常 1–3 个月
默认一天一圈
结构性假设，待实测
核心诉求：中小企业缺的不是需求，
是「付得起的定制」。
传统软件供给有四重错配，而 Agent 已经把「实现」这一环打平了。我们要做的，是把价值重心后移到 想清楚、验证对、上线稳这三件事上，并把它们装成一台买得起的机器。
四重错配：为什么这个市场长期空着
100 人以下的非科技企业，是目标客群
贴合度太低
只能覆盖 IM／CRM／电商等标准域，企业真正用得上约 20%，剩下 80% 的流程退回 Excel ＋ 微信群。
根本养不起
3–6 个月起步。产品、研发、测试、运维、PM 是一整套，不是招一两个人就能补齐的。
交付即终点
一次性交付、改一次收一次钱。第二年就没人维护，系统迅速变成新的历史包袱。
很多人没有电脑
业务员、仓管、班组长、店长，手上只有一部手机和一个微信号。要回办公室登录的系统，在他们的动线里不存在。
供给侧变了：瓶颈整体后移
这是产品形态成立的前提
功能实现
从「周／月」压到 0→1 一天内。写代码不再是瓶颈，也不再是壁垒。
想清楚要什么
需求质量决定一切。所以用户端不设聊天框，只收结构化待办，让 Agent 承担追问与拆解。
验证是否真的对
只能在真实设备、真实业务里验。所以每次变更都要留可复现的验证证据，而不是一句「已通过」。
上线与治理
环境、分支、回滚、密钥、审批、审计。这些不进 Agent 的思考，而是做成结构性约束。
我们的答案：一软两端
重的一半装在企业，轻的一半交到手上
产研脑 = 装了 DSH 的机器
软件本体是 @deepseek-ai/dsh（MIT，开发者预览）。批次调度、多角色编排、自验证、出预览都在这里。
小程序 = 唯一入口
只有三个动作：许愿、看进度、验收。扫码即用、微信身份免注册、语音是主力输入法。
FDE 把 0→1 立起来
场勘、建项目、做 demo、迁到客户机器、交接。此后 1→N 全靠企业自己许愿。
我们卖的不是一套软件，也不是一次开发，而是「企业常用软件的高频定制化服务」。 SaaS 卖固定功能集，你只能等它迭代；外包卖一次性交付，改一次收一次钱；我们卖一个会持续变形的功能集——推动它变形的，是企业里每个人说的一句话。
四条切分线：所有设计取舍都从这里来
违反任何一条，产品就会退回成「又一个要学的工具」
待办是一等公民
所有需求都必须落成一条待办，没有「直接喊一嗓子让 Agent 改」的旁路。
做一个聊天框让业务人员直接指挥 Agent（不可追溯、不可排期、不可验收）
0→1 归 FDE，1→N 归业务
FDE 的产出不是「一个系统」，而是把一个不可许愿的领域变成可许愿的领域；落地之后，改进的边际成本趋零。
期待客户自己从零描述一个完整产品
手机是唯一终端
不假设任何人有电脑。从扫码到验收必须在同一台手机上闭环，Agent 交付的系统也必须在手机上可用。
让业务人员「回办公室用电脑提交」；交付一个只有 PC 后台的系统
计费锚在「业务量」上
需求会枯竭（提完就没了），业务量不会（单据天天在跑、设备天天在读数）。收入主体应是每次干活消耗的算力。
按「提了几条需求」收费；把订阅做成「需求配额包」
不要靠「卖需求」赚钱，要靠「卖耗材」赚钱。 服务得越好、需求满足得越快，收入就越早见顶——这是「卖需求」的死局。改得越少、跑得越多，生意才越健康。
基础流程：白天收，晚上跑，
第二天早上在手机上验收。
全系统只有一个循环：一天一圈。业务侧只做许愿、看进度、验收三件事；中间的去重、澄清、排序、规划、编码、验证、发布， 全部由需求引擎与产研脑吸收掉。
一天一圈：五段节奏
钟点可配，此处为默认值
① 收集
随时可提，不打断任何人。站着、在仓库、在外面都能提；语音 ＋ 拍照是主力输入。
② 锁版发版火车
冻结本批次清单，生成版本号与影响面：涉及哪些应用、哪些数据模型、是否高风险。
③ 规划
拆解、依赖排序、风险标注、预计影响文件。方案先出，再动手。
④ 执行＋自验证
设计、编码、构建、部署预览，四道闸全绿才准出；不通过自动返工，最多两轮。
⑤ 回执＋验收
订阅消息推到手机：改了什么、在哪看、验哪三点。验收通过即关闭，打回自动派生新待办。
主链路：从一句话到一次真的变更
上行只有待办，下行只有回执，没有第三条通道
许愿与判定
- 语音／拍照／文字三通道，按住说话即可
- 重复、高度相似 → 并入已有待办，保留提出人
- 表述不清 → 挂起，给 1–3 个追问选项
- 结构完整 → 入池，成为本批次候选
公开与排序
- 全公司可见，按应用分组：看得见就不会重复提
- 附议：「我也要这个」，不产生新待办
- 管理员三档评级：急／常规／缓缓
- 只处理例外，默认零操作
锁版与执行
- 到点冻结：本批不可再变，输出影响面
- 四角色串行：产品 → 设计 → 编码 → 测试
- 四道闸自验证，不通过自动返工 ≤ 2 轮
- 产出变更集 ＋ 手机能开的预览链接
发布与回执
- 低风险自动发布；高风险等管理员一键批准
- 回执四行话 ＋ 两个按钮，禁止甩 diff
- 验收通过 → 关闭并计入吞吐
- 打回 → 带原文上下文派生新待办；异常 → 一键回滚
敢承诺质量，只靠这两件事
四道闸 ＋ 可反向验证的证据
真编译通过。不拿「日志干净」当通过——编译错误未必进日志。
命名约定、颜色／字号令牌不越界、禁写裸值、结构检查。
关键页面真实量测：宽度、对齐、溢出、深色模式，必要时真机截图。
与本批次影响面相关的既有功能判据全绿，不允许「顺手改坏」。
回执：这套产品的口碑点
手机上的四行字 ＋ 两个按钮
- 改了什么：采购单列表新增「按供应商筛选」
- 在哪儿看：点这里直接打开（手机就能看，约 1 分钟）
- 请帮我验：① 筛选后条数对不对 ② 清空筛选能否复原
- 没懂／不对：直接按住说话，说一句就行
为什么回执值得单独设计
- 它决定吞吐指标的分子
- 回执不到手机，这一批就长期挂在「已发布待验收」——挂住一批，等于吞吐掉一批。
- 它决定客户信不信
- 客户不懂技术，只会看「变了什么、去哪看、验什么」。回执是唯一一次「证明它真的干活了」的机会。
- 它决定下一批会不会来
- 打回可以只发一条语音。打字门槛高到会让人放弃反馈，而反馈是下一批的原料。
技术链路：小程序不直连 DSH
DSH 是可替换的执行引擎，后端才是产品中枢
扫码即用
计费 · 审批 · 回执
或 headless --json
append-only 可回放
生产经发布流程
冷启动：前三步由人推动，之后自己长
FDE 的成功指标是「自己被需要得越来越少」
先数电脑
数清全公司有几台电脑、都在谁手上；盘点在用的系统与表；标出企业站在阶梯第几层；找出「半个产品」的那个人。
先做最轻的那件
先做官网（犯错成本最低、一周见效），本地做可点 demo，第一次验收就在客户手机上打开，再迁移到企业机器。
把习惯种下去
把现有应用逐个建项目；陪业务提头 10 条愿望；教会管理员只处理例外，不逐条过。
业务自己许愿
愿望墙上公开许愿 → 评级 → 按批交付 → 验收沉淀。基础服务满足后冒出领域化需求，再外包一次 FDE。
远期设想：不是一家软件公司，
而是一家「仪器服务商」。
企业 IT 需求是一点点长出来的：先用上标准件，再靠许愿持续变形，最后把设备接进来。 收入也随之从「卖设备」转向「卖耗材」——只有耗材是随时间增长的。
成长阶梯：S1–S7，加一个横切维度
同一张图同时是交付次序、种子优先级、销售漏斗
OA
内部管理流程／权限／表单★ 首发
CRM
客户经营客户／跟进／合同有标准件
官网
对外形象内容／展示／表单★ 首发
后台管理
横切支撑录入／报表／权限随需
在线订购
对外交易报价／下单／跟踪有标准件
商城
对外交易交易／支付／对账★ 首发
领域化系统
行业专属排程／质检／巡检无标准件
服务模式：把 Agent 当仪器来做
只借它的商业结构，不借它的封闭性
成熟期收入结构：一次性 37% ／ 持续 63%
占比为推导假设，待真实客户测算；结构比数字重要
三条反模式：写死，不许商量
目标客户对「按量计费」天生恐惧，透明是成交前提
耗材只能用我家的
耗材不绑定：企业可以自带 API key（＝自带试剂），我们只提供省事、折扣与维保。
用量不透明
实时可见：每条业务动作消耗多少、本月累计多少、预算剩多少，管理员在手机上随时看。
超了不提醒
预算上限 ＋ 超限熔断：到位即降级，停批量任务、只保核心业务，绝不「先跑完再告诉你花了多少」。
路线：先把一圈跑通，再加柱子
P0 只做 1 家企业 × 1 个应用 × 1 天 1 批
证明「许个愿，第二天真的变了」
许愿端 ＋ 需求引擎 ＋ 执行体 ＋ 验证发布 ＋ 工程治理 ＋ 官网种子 ＋ 最小埋点。
证明「换个企业也能立起来」
多租户 ＋ FDE 工作台 ＋ 耗材账本／预算熔断／自带钥匙 ＋ OA 与商城 ＋ 硬件框架。
证明「不只写软件」
协议直连 ＋ 厂商自助接入包 ＋ FDE 服务市场 ＋ 多 IM 接入。
耗材成为利润主体
模板自动生成、跨企业经验迁移、行业方案包、耗材用量预测与包干定价。
看什么指标，不看什么指标
代码量、会话数、token 数都不是北极星
我们卖的不是软件，
是一台会干活的机器、
它每天消耗的耗材，
和偶尔上门的方法开发。
这句话里只有「耗材」会随时间增长——所以生意的重心必须放在「让客户天天用它干活」上， 而不是放在「让客户多提需求」上。这也是这套产品唯一不会打架的分工： 把 harness 当运行时，把产品逻辑放在外面。