Winston Builds

202628 个关键节点

11.10

Product Decision

每个业务组补一个聚焦 Build：三个空组全部补齐

按 PRODUCT_DIRECTION §2 方案 A，`/builds` 五个业务组里计数为 0 的三组（仓储与履约、采购与供应商、数据工程与治理）各补一个聚焦 Build：订单承诺 `customer-order-promise`（纯确定性 ATP / CTP）、RFQ 报价比选 `rfq-supplier-selection`（AI 只抽条款，TCO 与硬约束由确定性代码重算）、工程变更影响评审 `engineering-change-impact`（受限意图 + 确定性六域传播，迁移 agent-core）。聚焦 Build 不进首页旗舰位、不进推荐顺序；优先复用已归档实现的领域模型与测试，所有用户可见文字按 L1/L2/L3 分层规则重写。

WHY: 五个业务组有三个是空的，业务访客按自己所在的职能找实验时会落空；产品方向已裁决「每个业务组至少 1 个聚焦 Build」。三个旧实现（订单承诺 / RFQ / 工程变更）在 2026-11 收敛时归档，但领域模型与测试仍然有效，值得按今天的分层规则复活。
RESULT: 三组全部补齐，`/builds` 五个业务组每组 ≥ 1。真实模型评测（zhipu:glm-5.3，每题 3 次）：RFQ 条款抽取 16 回归 + 4 留出 pass@1 98.3%（唯一失败是一次未拒答而以正确抽取收尾，行为安全但不符合规格，如实落库）、留出 100%；工程变更受限意图 16 回归 + 4 新写盲留出同规格评测（数字见 `src/content/evals/results/`）。订单承诺无 AI，单测锁定数字。五组目录、空分组逻辑与计数脚本随波次对齐。
LEARNED: 旧 Build 的价值在领域模型与单测，不在文案：直接搬文字会把「证明 AI 能力」的旧叙事带回首屏；只搬模型、重写页面，改造量小且不回退分层规则。留出题首跑抓出的是题面缺陷与边界期望写错（如全角数字被误期望拒答），修题面重跑并把中间调试题跑不留档。

Product Direction §2 每组至少 1 个聚焦 Build ↗订单承诺 Build 源文档 ↗RFQ 报价比选源文档 ↗工程变更影响评审源文档 ↗

11.10

Product Decision

页面信息分层：第一受众改为业务访客，工程证据只进 L3

确认网站第一受众是懂业务、不懂实现的访客；页面按 L1 业务 / L2 判断依据 / L3 技术证据分层。首页去掉评测数字，旗舰卡改为业务可信说明；Build 卡片主区收敛为任务标题与业务问题，系统标签收到底部；排产 Build 文案改为业务说法；导航新增「工程」，工程架构与评测只在 /engineering 与各页 L3 可达。

WHY: 首屏原本同时讲模型、通过率与架构词，业务访客看不出页面帮他决定什么。技术评审者的内容仍需可达，因此做分层而不是删除。
RESULT: 本地生产构建（Playwright）核对首页与 /builds 卡片首屏结构；typecheck、test:models 50 脚本、test-build-discovery 与 build 通过。未做 1366 / 390 逐屏截图与子 agent 复述测试，线上验收待合并后进行。
LEARNED: 「第一受众」必须是页面文案的唯一排序依据：首屏只要出现模型或评测数字，业务访客就会把页面当成技术展示。分层规则需要测试守护（首页不读评测、卡片渲染 trust），否则很快回退。

Product Direction §1 受众与分层 ↗

11.10

Product Decision

库存问数页改为业务优先：先讲业务人员得到什么，再讲怎么做到

首屏由「5 张 KPI 卡 + 语义层原理说明」改为情况卡（三个业务处境 + 发生了什么/关键数字/要决定/怎样算答得好四问）+ 唯一主动作「问这个问题」，点击才实时提问、不预置答案；演示问题与评测题集分离（契约测试强制）；回答区中文表头、结论数字与查询结果加粗对应、span 驱动的业务三步进度；页面移入「计划与库存」分组；首页与「下一个旗舰」导航的 F1/F2/F3 内部编号全部下屏。

WHY: 页面原本讲机制（语义层、SQL、闸门、准确率），业务访客看不出这页帮他做什么决定，像普通 BI 看板；按 PRODUCT_DIRECTION §1 第一受众（懂业务、不懂实现）调整讲法，定位不变——仍是数据 Agent 能力展示，库存只是载体。
RESULT: 本地真实运行（zhipu:glm-5.3）：起手问题 3×3 全过——呆滞金额三次均为 18,800 元、断货物料三次均为电源模块、预测类三次均正确拒答或澄清，无问法回退；合并部署后线上冒烟：呆滞 18,800 元 ✓、断货电源模块 ✓。「问到数据之外」场景线上 3 次均未按期望拒答（1 次把已确认计划出库错位当「下月用量」作答、1 次被数字落地校验兜底拦截、1 次澄清）——拒答稳定性是提示词层面的既有问题，另开轮处理。typecheck / test:models 47 脚本 / build / CI 全绿。
LEARNED: 模型文本里夹带的内部标识不用改提示词：表名、枚举、别名都有确定性集合，展示层映射 + 未知原样保留即可；但「数据里没有的」场景的拒答是模型判断而非规则——本地 3/3 拒答不代表线上稳定，发布前冒烟必须覆盖拒答题。

改版执行文档与逐项记录 ↗

11.10

Product Decision

供应商延期页改为业务优先：情况卡 + 结果主角，评测与轨迹降为附录

Control Tower 产品页按第一受众（懂业务、不懂实现）重做主路径：页面标题改任务式「供应商延期应对：缺口、方案与谁拍板」；主推 3 个需要决策的场景（业务处境句），minor-delay 等反向对照收进「更多边界情况」并写明证明什么；运行前给情况卡四问，运行中显示 span 驱动的业务四步进度，运行后处置结论成为视觉焦点；原始轨迹收进「查看技术轨迹」折叠，模型评测对照收进「可靠性评测（技术附录）」折叠，工业系统语境移出首屏；变体切换与供应商备注默认收进「试试看」。模型生成文本里夹带的场景 id、处置/方案/校验枚举、责任角色与错误码经 report-copy.ts 展示层统一转中文。

WHY: 评审记录（docs/reviews/2026-11-10-page-drift-root-cause.md）判定该页做成了「给工程师看的自证材料」：标题是行业泛称 + 架构主张、运行轨迹占中栏、评测表一级位置、场景文案是测试断言口吻、供应商备注默认注入。根因是页面忠实还原了按架构写的产品定义；R1–R11 规则当日已写入权威文档，页面本身尚未改造。
RESULT: 本地生产构建真浏览器验证（chromedriver 1366×768 / 390×844）：首屏为页头、工作台说明、主任务区，评测附录与工业语境均在视口外；4 次真实运行（zhipu:glm-5.3，本地）验证主路径与失败路径——情况卡四问渲染、四步进度依次点亮、停在审批点、批准后报告为视觉焦点且推荐方案/责任角色/结论均为业务语言；第 4 次运行委派两次超时，页面如实停在审批点并给出「无推荐方案 + 人工介入」而非编造结论。typecheck / test:models（50 个脚本，含 4 个新增测试）/ build 全绿。
LEARNED: 不改提示词也能把「模型生成文本夹带枚举」压下去：枚举、角色、错误码都有确定性集合，展示层映射 + 未知原样保留即可；但场景 label 自带「：说明」段时，替换会产生「基准异常基准异常：185 件真实缺口」式的重复，这类残留要在真实运行里看到才知道。

评审记录：页面跑偏的文档根因 ↗

11.09

Design Decision

首页孪生落地「GLB + 命名约定」资产管线：机械臂率先换装资产级模型

调研 smart-warehouse（MIT）后落地单件试点：从上游全园区 GLB 切割六轴机械臂子图（31KB / 644 tris，节点重命名 TwinRobot_*，去其纸箱件），首帧后 dynamic import GLTFLoader 懒加载，按「offset = 节点位置 − Base 原点」统一归一装配，热替换 5 台程序化臂；材质运行时重定向为本站洁净材质族（白喷塑+石墨，上游赛博青色不出现）；补转台 Y 轴缓摆 + 腕环 Y 轴快摆点动（各线相位错开，still 冻结）。资产路线（GLB + 命名约定绑定 + 动画全代码驱动）与来源决策定稿于 HOMEPAGE_DIGITAL_TWIN_PLAN §14。

WHY: 五轮程序化写实改造后判定真实感上限在几何（无倒角、无装配细节、每线全同构）；Poly Haven 的 CC0 道具全是做旧、洁净现代设备只有付费/Sketchfab——MIT 上游资产绕开了这个死结。实测先修正了预期：上游质感来自 42 材质分级与 831 命名节点的细节编排而非面数（其臂 656 tris 仅约程序化臂两倍），试点目标是「造型升级」而非「密度升级」。
RESULT: GLB gz 传输 6.9KB（≤1.5MB 预算的 0.5%）、7ms 拉完热替换不重启动画；draw calls 74→73（≤80）、triangles 14.7k（≤150k）；typecheck / build / test:models / test:lazy-three / test:home-twin 21 断言全绿；前后截图对比（artifacts/home-twin/asset-arm-*.png）确认「细棍 → 圆肘关节+弧形前臂+粗壮基座」的造型增益；MIT 出处记录于 public/models/LICENSES.md，上游源文件存 docs/ref/ 不随站点发布。
LEARNED: 上游只发布 GLB 成品（无 .blend 源）——几何不可改、材质可全换，「命名约定」让「抄做法不抄资产」成为可执行管线；另外 3000 端口被旧 next start 占用时，新构建的 chunk 404 会让 hydration 静默死亡（mode 卡 pending、无 console 报错），浏览器验收前先核对端口占用与 buildId 一致。

任务权威 HOMEPAGE_DIGITAL_TWIN_PLAN §14 ↗上游参考 smart-warehouse (MIT) ↗

11.08

Design Decision

首页孪生动线收敛为「主角料箱 9s 完整循环」，布局动线评审终局化

AGV 均速环绕之外新增主角料箱叙事：2 台料箱按「L3 停 1.6s → 短驳到 L4 3s → 停 0.6s → 主线入仓 3.8s」9 秒循环（相位差 4.5s），任意 5 秒窗口可见一次完整方向；新增空箱回程 AGV 沿南侧人行道向西把视线带回 CTA；L3 警示塔灯罩加呼吸脉冲。同晚 review-panel 三席重开一轮补齐 C 席终局性：票型 A/B/C 平票，主席裁定采纳「红点脉冲 + 动线区域差分断言」，否决「引导线/放大卡/收束动线」的重改路线。

WHY: 均速环线抓拍可能一张都看不到入仓，「一条路、三个站点」的叙事需要一条可追踪的单一时间线；评审团 A 席指出叙事起点太安静、C 席指出 19 断言没有一条覆盖动线可见性——绿灯可能伪装成功，故把断言补进门禁（19→21）。
RESULT: 复用 InstancedMesh 与既有动线曲线，74 draw calls（预算 ≤80）、60fps；test:home-twin 21 断言（新增动线区域 1.3s 像素差分 ≥300）、test:models 39 项、test:lazy-three 全绿；1440×900 真浏览器截图复核站牌可读。
LEARNED: 评审平票时主席裁定的抓手是「最小改动兑现跨席共识」：两席质疑命中的 B 案（违反颜色纪律、拆掉待确认卡载体）被否决，而各席都认可的红点脉冲与位移断言当天落地；WebGL canvas 未开 preserveDrawingBuffer 时，像素断言必须在 rAF 后立即采样，否则读到的是被清空的 back buffer。

任务权威 HOMEPAGE_DIGITAL_TWIN_PLAN ↗

11.08

Design Decision

首页改为循环工厂数字孪生，退役滚动卡点叙事

首页首屏换成浅色自循环的工厂数字孪生（5 条产线、L3 停机红灯、L4 承接加速、AGV 动线、仓库收口、双大屏），文字层左下锚定问题与唯一 CTA 深链排产实验；三幕滚动/点击接管叙事段与白底工作台预览段整体退役。

WHY: 卡点式叙事考验访客对网站的理解——不知道要滚动/点击的人，再怎么提示也不知道干什么；而场景自己一直动，看懂看不影响继续浏览。场景状态全部派生自排产模型（previewScenario），与首页文案互证，延续「数据同源、诚实标注」的既有评审纪律。
RESULT: 纯 three 0.180 零新增依赖；实测 60.5fps、43→69 draw calls、613 可见实例、LCP 元素为 H1 文字（Fast-4G ≈1.3s，同法对照旧版略优）；窄屏/reduced-motion/WebGL 失败有设计过的浅色海报兜底；test:home-twin 19 项断言与 verify-lazy-three 门禁全绿。
LEARNED: 浅色场景的可读性靠「低饱和设备色 + 语义灯色点睛 + 纸白雾」而不是材质堆料；动画是否在走用截图差分断言，比依赖 dev-only 钩子更贴近生产真相。

任务权威 HOMEPAGE_DIGITAL_TWIN_PLAN ↗

11.07

Architecture Decision

收敛为三个旗舰并启动 Agent Core

其余 29 个 Build 与 2 个 Product 已下线，只保留 F1 库存分析 Agent、F2 生产重排 Agent 与 F3 供应链 Control Tower；下线内容的代码保留在 git tag archive/pre-agent-core-2026-11，站点不再为其维护页面或兼容层。

WHY: 31 个 Build 同质化地证明「调用一次 LLM 输出 JSON → 代码校验」，无法继续叠加新的能力证据；转向真正的 Agent 循环、工具调用、审批检查点与可复现评测，需要把维护面收敛到三个能做深的旗舰上。
RESULT: 构建、类型检查与 18 个测试脚本全绿；注册表、孤儿模块、测试清单与 CI 已同步收敛，删除内容全部可从归档 tag 找回。
LEARNED: 证据密度比数量更重要：删除不是损失，前提是归档 tag 可回溯、叙事（README 与 case study）跟得上新方向。

归档 tag archive/pre-agent-core-2026-11 ↗

11.02

Architecture Decision

全面退役 Supabase：三个 Build 的会话状态迁到访客浏览器，会话 API 无状态化

排产、仓储、工厂三个有状态 Build 的会话从共享 Supabase 表迁到浏览器 IndexedDB（版本号乐观并发、12 小时 TTL）；服务端 API 只校验与计算、不再存任何会话；telemetry 同步退役为结构化运行时日志。

WHY: 会话本来就是按访客浏览器隔离的合成演示状态，外部数据库只带来一个跨洋依赖和一个本地开发被墙的单点；状态放浏览器后，数据访客可自控，服务端不再持有任何会话存储。
RESULT: 真实 glm-5.3 浏览器验收：排产候选→刷新持久→双标签冲突检出并恢复一致；仓储上架 28/72→29/72 刷新保持、重置回基线；工厂故障注入→分析→批准→刷新保持。typecheck、build 与 38 个测试脚本全绿。telemetry 持久化历史随 Supabase 一起退役，诊断历史以平台运行日志为界。
LEARNED: 服务端保持无状态是迁移低成本的关键：领域逻辑与 AI 调用位置不变，只有存储换层；双标签页冲突必须在保存时校验版本号，否则会静默覆盖；页面声称（Supabase 会话）与实现必须同批修改，否则违反证据纪律。

排产工作台 →Infrastructure ↗

10.31

Architecture Decision

排产从分步演示迁为工作台，AI 只提意图，规则与人保留生产决定

库存 Agent 的看板与对话模式迁移到生产重排：同源甘特、最近四轮记忆、双端受限动作闸门、人工比较批准和五维真实模型评测；确定性排程优化器保持独立，不引入库存 SQL。

WHY: 自然语言应该降低理解扰动与查看权衡的门槛，而不是让模型拥有生产分配、产能计算或批准权限。
RESULT: glm-5.3 实测经历交期契约、越界分类与空字段闸门失败；修复后同一24题连续三次全过、16题回归均全过。无头 Edge 走通多轮候选、拒答、人工保存及窄屏路径；仅为模拟会话与该次题集证据。
LEARNED: 模型字段必须对应真正可执行的领域动作：普通需求增加的交期应由代码继承；安全空字段可以规范化，但非空越权字段与直接批准仍必须阻止。

排产工作台 →领域 PRD 与真实失败记录 ↗

10.31

Learning / Correction

排产评测从「全绿」改为留出题与三次复测，并承认下限越界仍不稳

把 24 题扩到 34 题：S01–S16 为回归，S25–S34 为提示词定稿后新增的留出题；提示词删去评测题原文，改为通用规则；缺省偏好由代码补默认，空对象视为未提供，闸门拦下的越界值单独标注。

WHY: 同一套题既调提示词又打分，24/24 衡量的是记住题而不是规则；展示给访客的成绩必须能经得起没见过的问题。
RESULT: v5–v7 各三次真实运行，总分 30–32 / 34，回归基本 16 / 16；停机 1 小时、数量 30 台这类低于下限的请求，模型仍常澄清或直接生成候选，由代码闸门拦下。结论：闸门有效，模型识别不稳，不宣称泛化。
LEARNED: 提示词不写题面原文；留出题与回归题分开计数，据某题调优后该题转入回归；越界值靠代码闸门兜底，评测单独标注「闸门拦下」，不算模型拒答能力。

排产工作台 →评测版本与失败记录 ↗

10.26

Design Decision

首页从白底克制版改为三幕卡点 3D 叙事，数据与工作台同源

首页改为暗色三幕叙事（停机 → 候选 → 人工拍板），之后回到白底排产工作台。3D 由纯 three.js 懒加载；文案与订单数字 SSR 直出，全部由 previewScenario 确定性模型派生。滚动最终采用「一次手势一幕」接管，末幕交还原生滚动。

WHY: 白底 V3 首页 5 秒内给不出「工业 AI 实验空间」的记忆点。评审团裁决合成方案后，又依据 winstonwang.space 首页的真实使用反馈，把 CSS scroll-snap 改为手势接管。
RESULT: verify-home-takeover 断言全部通过；three.js 不进首屏 SSR HTML；窄屏、无 WebGL 与减弱动效均降级为同文案静态段。
LEARNED: 视觉升级不改变真实性红线：候选始终标为待确认、保留 SIM 标注、不放虚构指标；3D 端只取模型输出的标量，不维护第二份手写数据，避免图文漂移。

决策记录 ↗UX Design Spec §20 ↗

10.26

Architecture Decision

生产托管从 Vercel 迁到 EdgeOne Pages，CI 以「线上版本号 = 本次提交」作为交付门禁

build.winstonwang.space 改由 Tencent EdgeOne Pages 从 main 自动部署，Cloudflare 只做 DNS，Vercel 退役。scripts/build.mjs 在 next build 前注入 git 提交号写入页面 build-revision；CI 推送 main 后等待线上返回同一提交号，再对生产站跑浏览器复核。

WHY: 个人主站的子站统一采用 EdgeOne + Cloudflare DNS；同时此前出现过部署被阻塞、线上不是最新却无人察觉的情况，交付是否到位需要可机器检查的证据。
RESULT: 首个 EdgeOne 路径全绿 CI 为 run 40277744460：本地 Chrome 套件、生产版本门禁、Order-to-Delivery 与代表性 Industrial AI 页面的生产浏览器复核均通过。
LEARNED: EdgeOne 没有预置提交号变量，版本号必须由构建脚本自己注入；「部署成功」以线上可读到的版本号为准，而不是以平台状态页为准。

Infrastructure ↗CI run 40277744460 ↗

10.23

Architecture Decision

三个 Product 完成「正经上线」冲刺：three.js 异步化、AI 挂起兜底与交互语义补齐

评审团（A 产品 / B 交互 / C 工程）收敛后落地：Factory Twin 的 3D 模拟器拆为异步 chunk（three.js 不再阻塞 Product 页首载）、客户端 AI 请求补超时兜底（弱网挂起走确定性回退）、agent-team 首屏补主动作、AI 浮层可关闭、移动端 3D 手势与 aria 语义修复；新增 Product 详情页浏览器验收门禁 test:products-browser。

WHY: 三个 Product 的交互主路径已经可用，但作为可对外上线的作品仍有可观测缺口：favicon 404、非首屏 3D 资源阻塞首载、弱网下 AI 请求无超时可无限挂起、移动端 3D 画布锁死页面滚动、动作后果留在视口外。
RESULT: test:products-browser 全绿（4 页 × 桌面/移动、三条主路径交互、内链健康、无运行时错误）；three.js 移出首屏 chunk；懒加载后的 twin 完整交互链（注入 → 选方案 → 批准 → 订单工作区）经真浏览器回归。决策与未做清单见 docs/reviews/2026-10-22-product-launch-sprint-review.md。
LEARNED: Next 16 会把非 localhost Host 的 dev 资源当跨域封锁，导致全站静默不水合而静态文本测试照绿——交互验收必须断言真实点击生效。上线标准不是更多功能，而是把「挂起、遮挡、锁滚、断链」这类可观测的洞逐个关掉。

决策记录 ↗

09.22

Product Decision

Portfolio 从 Supply Chain-only 扩展为 Industrial AI Systems

保留 Supply Chain / Manufacturing 作为当前最强证据主干，同时引入 industry baseline、AI augmentation / AI-native、工业系统术语和 Decision Rights 作为新的 portfolio framing。

WHY: 现有 Build 功能与真实工业问题已经较接近，但自定义命名、供应链单一坐标和通用 Human Approval 让招聘者与行业读者需要自行翻译；同时无法准确容纳 PLM / CPQ / Engineering front-end 等新的真实工业问题。
RESULT: PRODUCT_DIRECTION、INFORMATION_ARCHITECTURE、PAGE_CONTRACTS 与 BUILD_OVERVIEW_MAP 已更新；Supply Chain × AI Map 降为 operations lens，后续重构将先修改内容模型和行业语义，再决定页面视觉改动。
LEARNED: 作品集的价值不只来自功能覆盖。先说明行业已经解决了什么，再说明剩余 gap、AI delta 与责任边界，才能证明真正的工业理解和系统判断。

Product Direction ↗Information Architecture ↗

09.22

Product Decision

Exception Command Center 演进为 Supply Chain Control Tower

把单一 Supplier Delay 闭环提升到 shared network state、双重 Root Event、Impact Provenance、P1–P4 Priority 和跨域 Recovery Scenario，同时保留原 14 个异常恢复 fixture 作为回归层。

WHY: 单异常闭环已经证明局部恢复逻辑；下一步需要验证的是多个扰动同时发生时，系统能否解释影响传播、决定先处理什么，并避免把局部风险静默转移到其他节点。
RESULT: 新增 11 节点供应链网络、Supplier Delay + Machine Breakdown guided flow、3 个 What-if Recovery、Human Gate 和 8 个 Control Tower fixture；没有引入新数据库、Event Bus 或 Agent Framework。
LEARNED: Control Tower 的价值来自共享状态、可验证传播和决策边界，不来自地图或更多 KPI；已有 Engine 应作为能力被组合和回归，而不是复制重写。

查看 Product →PR #45 ↗

09.21

Major Build

数字孪生从 3D 展示升级为状态驱动 Product

建立 Factory Digital Twin Command Center，把 5 条产线、20 个工位、异常传播、What-if 恢复、AI 解释和人工授权连接到同一 Twin State。

WHY: 单纯用 3D 模型复刻工厂只能证明视觉实现；真正需要验证的是空间对象、业务状态、仿真、约束和恢复决策能否共享一套可重复模型。
RESULT: Three.js 只负责空间视图，TypeScript Twin Engine 负责设备状态、WIP、KPI、传播和 Hard Constraint；3 类异常与 9 个 fixture 提供可重复证据。
LEARNED: Digital Twin 的成熟度不取决于模型面数。先把状态模型、异常因果、What-if 与责任边界做正确，再决定是否需要更高保真资产。

PR #44 ↗

09.20

Product Decision

页面目标从实现细节中独立出来

新增 Page Contracts，为核心页面定义稳定的 visitor outcome，而不是冻结当前布局。

WHY: 连续 UI 调整已经证明：如果只有实现规范，没有页面级目标，局部优化很容易破坏第一次访问者真正需要完成的任务。
RESULT: 首页、Build、Product、Capabilities 与 About 都有了明确的页面职责、首屏任务、主操作和不可破坏条件。
LEARNED: 布局可以持续变化，但页面存在的理由必须稳定；Source of Truth 应保存目的，而不是把当前 UI 固化成永久规则。

Page Contracts ↗

09.18

Design Decision

Exception Command Center 改成 Visual-first

把 prose-heavy 产品说明压缩成 Input → AI → CODE → HUMAN、影响传播、方案比较和 Human Decision 等视觉流程。

WHY: 真实浏览器检查发现，系统逻辑虽然完整，但关键判断被大量说明文字淹没，第一次访问者的阅读成本过高。
RESULT: 详细 rationale 移入渐进披露，核心责任边界、KPI、恢复方案和授权结果留在主阅读路径。
LEARNED: 完整信息不等于一次展示全部信息；Evidence 应该 progressive disclosure，主路径只保留理解当前决策所需的内容。

查看 Product →PR #40 ↗

09.18

Learning / Correction

Product 从 Happy Path 扩展到 Failure Handling

Exception Command Center 增加 6 个业务场景和 8 个失败场景，并补上强制 Human Escalation。

WHY: 单一成功路径只能证明 Demo 能跑，不能证明系统知道什么时候不该相信 AI、什么时候没有可行方案、什么时候必须升级给人。
RESULT: AI master data 校验、fallback、缺失数据、约束违规、无可行恢复方案等失败边界都变成可重复验证的 fixtures。
LEARNED: 成熟度来自边界验证而不是功能数量；Negative path 和 escalation evidence 是 Mature Product 的核心证据。

查看 Product →PR #38 ↗

09.17

Major Build

建立第一个跨模块 Supply Chain Exception Product

Supplier event → Inventory impact → Order / Scheduling impact → Recovery Plans → Human approval 被整合成一条完整工作流。

WHY: 单独的 Idea Builds 可以证明局部能力，但还需要一个 Product 来证明业务逻辑、AI 边界和已有模块能否形成完整系统。
RESULT: 复用现有 Inventory 与 Scheduling 模型；AI 只做结构化事件提取，核心计算保持 deterministic，最终恢复授权由人负责。
LEARNED: Product 不应该通过复制已有逻辑变大；成熟系统更重要的是把已有能力组合成清晰、可验证的责任边界。

查看 Product →PR #37 ↗

09.17

Learning / Correction

真实浏览器验收推翻“必须塞进一屏”

Build Detail 的 CTA 一度只有约 9px，辅助文字出现 8–11px；随后建立最低可读性约束并放松固定高度。

WHY: 为了追求单屏体验，页面把内容压得过小；结构更紧凑了，但实际阅读反而更差。
RESULT: 按钮、正文和辅助标签建立可读性底线；“下一步”状态改成明确文字提示，避免双高亮歧义。
LEARNED: Single viewport 是手段，不是目标。只要可读性被牺牲，就应该允许页面自然增长，而不是继续压缩。

PR #35 ↗

09.17

Design Decision

Guided Story + AI System Proof 成为共享模式

把试点中的 state-driven tabs 提升为站点级模式，并将业务故事与 AI 系统证明拆成两个层次。

WHY: 不同 Build 需要自己的业务因果顺序，但招聘者也需要一致地看懂 AI 在哪里、CODE 做什么、人保留什么权力。
RESULT: 共享 BuildStoryTabs 与 AI System Proof 被逐步推广到现有 Build，而不是强行使用一套固定四 Tab 模板。
LEARNED: 可复用的是交互与证明结构，不是业务流程本身；共享模式应该约束理解方式，而不是抹平 domain 差异。

PR #25 ↗PR #30 ↗

09.17

Product Decision

Builds 首页从卡片库存变成能力地图

/builds 先展示 Supply Chain × AI Competence 的整体分布，再进入完整 Gallery。

WHY: Build 数量增长后，直接展示大量卡片只能告诉访问者“很多”，却不能快速解释这些实验覆盖供应链哪些阶段和 AI 角色。
RESULT: 访问者先看到 portfolio 的形状、覆盖与 AI participation，再按需进入单个 Build。
LEARNED: 集合页首先应该解释结构，而不是展示库存；Technology 更适合作为维度和 metadata，而不是内容组织主轴。

查看 Builds →PR #32 ↗

09.17

Architecture Decision

开发流程改成 CI 验证、任务完成后统一部署

停止 feature branch 的自动 Vercel Preview 风暴，把 GitHub CI 作为开发中的默认质量门槛。

WHY: 频繁小改动不断触发 Preview，消耗有限部署额度，也让“代码检查”和“最终交付验证”混在一起。
RESULT: 非 main Git build 被跳过；相关改动先在 branch 累积并通过 CI，任务形成完整批次后才进入一次正式部署。
LEARNED: 验证强度应该跟变化规模匹配；部署是 delivery step，不应该成为每次编辑的副作用。

PR #21 ↗

09.16

Major Build

Supply Chain Agent Team 成为第一个正式 Product

多角色 Agent 分析、有限协商、Action Catalog、deterministic guardrails 与 Human Review 被组合成完整案例。

WHY: 需要验证的不是“多个 Agent 能聊天”，而是多个 AI 角色在有限上下文、成本和错误边界下能否形成受控协作。
RESULT: Agent 可以讨论和提出动作，但 KPI、硬约束、可执行动作以及高影响决策仍由确定性代码和人控制。
LEARNED: Agent autonomy 必须被任务边界、轮数、并发、Action Catalog 和人工升级机制约束；Agent 不天然拥有执行权。

PR #10 ↗

09.16

Product Decision

网站从文章式 Portfolio 转向 Demo-first Proof of Work

确立 SEE → TRY → OBSERVE → UNDERSTAND → VERIFY，并把“Experience first. Evidence behind.”写进页面架构。

WHY: 原有页面更像博客或案例文章，访问者需要先读大量解释才能发现真正可运行的系统和判断证据。
RESULT: Build Gallery、stage-first detail、distinct Product archetype 和 progressive disclosure 成为新的站点结构。
LEARNED: 对技术 Portfolio 来说，解释不能先于证据；应该先让访问者看到系统行为，再允许继续深入架构、限制与实现。

PR #4 ↗

09.16

Architecture Decision

建立可跨项目复用的 UI Capability Library

新增 @winston-builds/ui 与 /design-system，把通用体验框架和解释型可视化从具体 Build 中抽离。

WHY: Build 数量和仓库会持续增长，如果每个项目都重新实现相同的体验模式，视觉一致性和验证成本都会迅速恶化。
RESULT: 共享 tokens、Experience primitives、BoundaryFlow 和 visualization patterns 可以版本化复用，同时 backend、AI runtime 和 domain algorithms 仍留在应用内。
LEARNED: 应复用稳定的 capability pattern，而不是抽象整个应用；共享组件不应该接管业务路由、状态或 domain authority。

UI 模块库 →PR #3 ↗