甜小粒标识 甜小粒科技 聊聊 AI 场景

实施与交付

从一个场景,
走到可验收的交付。

先确认业务问题,再确定系统与 AI 的分工。我们把工作拆成可检查的阶段,用原型对齐使用方式,用接口与测试约束实现,最后按约定范围交付源码、文档和部署说明。

12 需求阶段文档,按项目规模分小、中、大三档裁剪
267 ↔ 267 需求与接口操作标识逐条对应,零缺零溢
21 项发现 最近一轮四视角复核,其中 17 项缺陷已修
立场

合作前,先对齐判断依据

项目实践、人员安排与资质要求都会影响合作选择。以下说明当前情况,并明确可以检查的交付依据。

案例数量

公司名下尚无带盖章验收的客户业绩,我们不拿数量说事,也不借他人的成果充数。能摆出来给你看的,是过程产物本身——需求文档、接口契约、门禁记录、复核结论。

产品与技术分工

产品经理负责需求分析、业务流程、原型与迭代协同,技术负责人负责架构、实现和运行保障。双方共同确认阶段产物与验收要求,支持你方检查或委托第三方复核。

资质证书

资质情况与实际实施工作分别说明。交付文档按 CMMI 过程域组织(需求→设计→测试→验收→追溯),本公司未申请也未取得 CMMI 评级。

链路

交付链路展开:每一步的产物是什么

每一步都有可检查的产物和验收要求。具体文档与验证范围按项目规模裁剪,并在开始前与双方确认。

七个步骤,每步都有确定的产物

需求:产出 12 类文档,按项目规模裁剪

业务需求 → 需求规格 → 迭代需求 → 原型说明 → 接口需求 → 数据字典 → 权限矩阵 → 状态机 → 验收标准 → 需求追踪矩阵 → 变更单 → 评审清单,共 12 类。小、中、大三档项目裁剪出不同的文档集,不是每个项目都套同一份模板。

设计:把被否掉的方案与理由一起交出来

产物为分层架构视图、具名架构决策记录(每条记录写明当时被否掉的方案以及否掉的理由)、量化质量属性、风险登记册、部署拓扑,并用脚本校验模块依赖图无环。实证规模:12 章节架构基线、13 条决策记录、6 项量化质量属性、16 条风险登记、2 张部署拓扑。

契约冻结:需求逐条转成接口契约文件

实证:267 条需求 ↔ 267 个接口操作标识,逐条对应,零缺零溢,多一条少一条都要说明来由。同时产出数据传输对象与实体表的血缘映射,以及 122 个状态对象的状态机契约。

质量门:审核方自己写解析器独立重算

审核方不复用产出方的脚本、不采信产出方的自述,自己写一套解析器把全部数字重新算一遍,逐项判通过、不通过或需人工。判为不通过的,必须实测闭合之后才放行。

验收:用真实浏览器逐页自动化验收

捕获页面错误并断言 JS 零错误;用上下文敏感的正则扫描开发期残留;断言导航注入正确、当前项高亮正确;再实际点通新增、编辑、状态流转、导出等关键动线,而不是只看页面能打开。

追溯:需求追踪矩阵八列双向串联

业务需求 → 需求 → 接口 → 代码 → 测试用例 → 验收标准,八列双向串联,由脚本实算覆盖率与跨模块依赖入度。未回填的列显式标注「待某期回填」,不留白假绿。

缺口挂账:开放问题登记成编号台账

一切需要另行拍板的开放问题,都登记成带编号的台账交给你。被阻塞的项计入「不通过」,不计入「跳过」——这一条决定了交付报告上的数字能不能当真。

第四步是与常见做法的关键差别。很多交付里的「已通过评审」,评的是产出方自己写的结论、跑的是产出方自己的脚本。我们要求同一份产物由两套独立实现各算一遍,对不上就返工。

机制

合作机制:把风险写进流程,而不是写进承诺

下面四条不是服务态度问题,是合同与流程上的安排。它们决定了万一合作不顺,你能在哪一步、以什么代价停下来。

阶段停止点

每个阶段结束都设一个停止点。在停止点上你可以无违约终止合作,仅结算通过验收的那些阶段的费用,未开工的阶段不产生任何费用。

首阶段「先做先看」

首阶段以小额启动,你先看到真东西再决定要不要往下走。该笔金额抵扣总价,不重复收费——它是总价的一部分,不是另收的门槛费。

范围外需求走增项评估单

范围之外的需求不口头加塞:2 个工作日内出评估单,写明工作量与对进度的影响;经你书面确认后才实施、才计费。未确认的,不启动、不计费。

开源件治理

每引入一个组件都实测许可证原文,不凭记忆下结论;记录来源、校验值与核对日期,登记成开源件清单随交付一并附送。这套做法已经实测纠正过三处凭记忆会写错的许可事实。

复核

独立对抗式复核

审查方与产出方分离,审查方不采信产出方的自述。复核结论连同未闭合的部分一起给你,而不是只给一句「通过」。

复核怎么进行

  • 审查视角与产出视角分离,各自独立取证,不共用脚本、不共用结论。
  • 不采信自述:凡是「已修复」「已覆盖」一类说法,都要在产物上重新实测一遍。
  • 每一项发现定位到函数与行号,让修复动作可核对、不含糊。
  • 修复之后重新复核,未闭合的条目照实留在报告里,不做合并、不做淡化。

最近一轮四视角复核

  • 提出发现 21 项
  • 缺陷已修 17 项
  • 复核结论:有条件通过

我们把结论原样写出来,包括它不是「审核通过」这件事。一份从不出现「有条件通过」的复核报告,本身才更值得怀疑。

这些产物的价值不在体量,而在于每一项都能被独立重算、被逐条追回它对应的那条需求。你需要的时候,我们把重算用的脚本和判据一并交给你,或者交给你指定的第三方。

想看真实的交付产物长什么样

把你手上的项目情况说一说,我们可以按你的场景讲清楚:会出哪几份文档、门禁怎么判、停止点设在哪里。

聊聊 AI 场景