同一零件的历史质量记录难以连续追溯。
MANUFACTURING QUALITY DATA PLATFORM
质检数据
全生命周期平台
从已上线的 V1 业务原型，到重新设计边界、权限与工程流程的 V2：我用真实制造质检场景验证产品，再用 AI Coding 与受控工程方法持续重构。
01
THE PROBLEM
问题不是没有数据，
而是数据没有形成系统。
在制造质检场景中，设备、零件、批次、检测记录和质量结果可能散落在不同表格与人工流程里。数据一直在产生，但历史记录、检测标准、权限边界和后续分析之间缺少稳定关系。
检测标准、版本与实际检测数据之间缺乏稳定关联。
不同角色能看到什么、修改什么，需要明确的服务端边界。
数据沉淀后，需要进一步形成台账、报告和分析依据。
我最先想解决的不是“给制造业加一个 AI 功能”，而是先建立一条可信、可追溯的质量数据链路。
02
PRODUCT MODEL
从“功能列表”，
转向“业务对象与数据关系”。
早期我会从仪表盘、检测录入、趋势图、权限管理等功能出发。随着复杂度增加，我开始围绕业务对象和生命周期重新组织产品，让一条质量记录从产生、审核到发布与追溯都有清晰来源。
Part零件主数据
→
Revision版本生命周期
→
Template检测模板版本
→
Batch / Instance批次与实物
→
Inspection现场检测与判定
→
Ledger / Report台账、报告与发布
单根组织树与多组织单元。
账号、可撤销 Session 与设备上限。
角色、权限、Data Scope、归属与状态联合判断。
关键业务写入与审计记录原子提交。
03
MVP / SCOPE
第一阶段不是做完整 PLM，
而是先跑通质量数据闭环。
V2 第一阶段被主动限定为单一制造企业、多组织单元、质量场景优先。重点不是把功能做全，而是验证真实零件数据能否稳定进入系统，并完成记录、查询、授权、报告、发布和追溯。
FIRST
- 组织、用户与授权
- 零件主数据与版本
- 检测模板与 Excel 导入
- 批次、实物与装配
- 检测、复检与基础不合格
- 台账、分析报告、审核与快照
NOT NOW
- 完整 BOM / ECN / ECO
- 完整 CAPA
- 多租户 SaaS
- IoT 实时采集
- 完整 ERP 集成
- AI 自动业务决策
Scope is a product decision.
04
AUTHORIZATION
权限不是“隐藏一个按钮”。
当管理员、质量管理人员、检验员、工程师与查看者进入同一系统后，权限开始成为业务本身。V2 将授权判断放在服务端统一入口，并把角色仅作为授权条件之一。
Identity+Permission+Organization+Data Scope+Ownership+State
前端隐藏按钮只是体验设计，真正的安全边界必须存在于服务端。
05
DECISION
有时候继续优化，
比重新开始更贵。
V1 很快完成了业务验证，但随着模块和账号权限持续增加，新需求开始频繁牵动旧结构。原本预估一周能处理的多账号权限，实际单个账号就需要约两天反复调整，这成为我决定停止修补的信号。
Fast validation
- 快速成型
- 功能优先
- 耦合逐渐加重
- 权限修改成本持续上升
→
Controlled rebuild
- 范围先冻结
- 领域对象先定义
- 授权与审计成为平台能力
- 测试、PR、CI 与 Human Gate 进入开发流程
检测记录、合格率、风险设备、趋势与质量洞察已经形成可操作的数据界面。
V1 已具备云端账号登录入口，证明项目不是静态设计稿，而是可运行原型。
支持 Excel 批量导入检测数据；这也是 V1 快速扩功能、最终积累复杂度的一个缩影。
06
AI-ASSISTED BUILDING
AI Coding 的问题，后来不再是
“代码能不能生成”。
轻量应用阶段，我的工作方式很接近“想法 → Prompt → Codex → 修改”。当项目进入权限、数据库、迁移、测试、架构和多模块协作后，纯聊天式开发开始失效，我开始把 AI 放进一个受控的工程流程里。
01Product Problem定义问题和成功标准
→02Scope / Slice限定边界与可验证目标
→03Architecture Decision记录关键取舍
→04Codex Implementation实现、测试与修复
→05Review / CI自动检查与独立审阅
→06Human Gate决定是否进入下一阶段
Slice 设计、产品与架构讨论、Review 标准。
实现、测试、修复、Code Review、PR 与 CI。
判断问题是否值得解决，定义范围、做关键取舍、设定验收标准并审核结果。
Codex 在 Slice 2C 中按约束推进实现、修复与 Closure；当前工作不再是一条 Prompt 直接做完，而是围绕 Slice、Review、CI 与 Human Gate 逐步收口。
AI 负责提高实现能力，人仍然负责判断。
07
ENGINEERING DISCIPLINE
当 Demo 变成长期项目，
文档开始承担系统记忆。
我逐步建立产品范围、当前事实、活动计划、架构和领域模型等权威文档，让人与 AI 的长周期协作尽量不依赖聊天上下文。
PRODUCT_SCOPE.md定义产品边界和第一阶段唯一实施路线。
CURRENT_STATE.md记录当前唯一事实状态，不让聊天替代事实源。
ACTIVE_PLAN.md同一时刻只允许一个获授权的活动开发计划。
ARCHITECTURE.md记录模块归属与技术边界。
DOMAIN_MODEL.md沉淀领域原则和跨模块语义。
Git / PR / CI保留可验证的开发历史和质量门。
把定位、用户、第一阶段业务范围、明确不做与实施路线写回仓库，作为 Agent 的长期事实输入。
用单一活动计划约束当前 Slice：允许做什么、禁止做什么、什么时候必须停。
目的不是写更多文档，而是降低人与 AI 在长周期协作中的上下文漂移。
08
DEFINITION OF DONE
验证，而不是“我觉得做好了”。
项目逐渐从“页面能打开”转向可重复的验证基线：lint、typecheck、测试、build、数据库校验、数据库生成、CI 和独立 review。当前 Slice 2B 的完成基线已经覆盖普通测试与真实 PostgreSQL 测试。
184ordinary tests passed
101PostgreSQL tests passed
0 / 0BLOCKER / MAJOR in review baseline
Lint PASSTypecheck PASSBuild PASSdb:validate PASSdb:generate PASSGitHub Actions PASS
Slice 2C Equipment foundation：Draft PR 保持未合并；页面可见部署成功、checks passed，同时仍保留人工合并门。
Implementation CI、Final CI 与 independent review 均有明确 closure 证据。
33 files / 184 ordinary tests、7 files / 101 PostgreSQL tests；master CI PASS 后才关闭 Slice。
当前证据边界：V2 master 的权威完成基线仍到 Slice 2B；Slice 2C 已有实现、Review 与 CI 成功证据，但 PR #12 仍为 Draft / 未合并，因此不把它写成 master 已完成。
注：这些数字对应当前 V2 Slice 2B 的已验证基线，而不是整个第一阶段最终完成状态。
09
CURRENT STATUS
V1 已冻结，V2 正在按受控路线重构。
作为业务验证原型保留，不再继续堆叠新功能。
View repository ↗master 已完成并合并 Slice 0～2B；Slice 2C 已形成 Draft PR #12，并通过当前 closure CI，但仍未合并，继续保留 Human Gate。
View repository ↗View PR #12 ↗先把质量闭环做深，再逐步沉淀可复用的工业软件平台能力。
10
WHAT I LEARNED
真正重要的，不是我做了多少功能。
AI 降低了实现门槛，但没有降低决策难度。
代码生成越来越容易，但产品范围、数据模型、权限边界和验收标准仍然需要人判断。
系统复杂度不会因为使用 AI 而消失。
Demo 阶段被隐藏的问题，会在真实业务、权限和数据关系增加以后重新出现。
做中学，比第一次就设计完整更有效。
V1 暴露的问题不是浪费，而是只有真正进入开发后才能看见的系统约束，它最终推动了 V2。
这个项目仍在继续。
我也仍在学习如何把产品判断、AI 工具与工程方法组合成更好的开发方式。