先写可验收的 SPEC，再让 Agent 生成代码
- 为什么这样选
- 配置平台的复杂度集中在状态和边界；先固定契约，才能判断生成结果是否正确。
- 没有选择
- 用口头说明或线框图直接进入开发
- 取舍
- 前期多花时间写规格，但减少了跨角色返工和验收歧义。
返回项目列表01 01 02
AI Coding 驱动的 Agent 配置平台
从产品方案到前后端实现的完整交付
产品设计与 AI Coding
2026.01 – 2026.09
已上线 · 已交付
2026-01-01
SPEC
Coding Agent
JavaScript
Go
AI Coding
AI 产品
Agent
平台产品
受保密限制AI Coding 驱动的 Agent 配置平台
30 秒摘要
我把配置类产品从口头需求推进到可上线功能：先用 SPEC 固化状态、异常与验收边界，再让 Coding Agent 参与 JavaScript / Go 实现，并与研发、QA 完成联调。
02
3 个关键数字
- 2
- 前后端实现层JavaScript 前端与 Go 后端
- 3
- 协作角色产品、研发、QA
- 4
- 交付阶段方案、实现、联调修复、上线
03
产品流程
- 01拆解边界
明确用户任务、权限和不可披露范围。
- 02编写 SPEC
固定页面状态、异常分支与验收口径。
- 03AI Coding
按规格生成 JavaScript 与 Go 实现。
- 04人工审查
检查业务语义、工程约束和失败路径。
- 05联调修复
联合研发、QA 定位跨端不一致。
- 06部署上线
用验收结果确认交付闭环。
04
两个关键决策
保留人工审查与 QA 门禁
- 为什么这样选
- 生成代码能加速实现，却不能替代对业务语义、异常分支和上线风险的负责。
- 没有选择
- 让 Coding Agent 自动生成后直接合并
- 取舍
- 交付速度不是最大化，但上线行为更可控、问题更可追溯。
05
一个 Bad Case
主路径可用，异常状态却跨端不一致
- 现象
- 页面在正常输入下运行，但失败、空值或重复操作时，前端提示与后端状态不一致。
- 诊断
- 初版规格描述了功能目标，却没有把异常分支写成双方共享的验收条件。
- 处理
- 补齐状态表、错误语义与回归用例，再联合研发和 QA 逐项校验。
- 结果
- 问题从临场修补变成可复用的规格与测试门禁。
06
结果与验证状态
已上线 · 证据受保密约束
相关功能完成开发、联调和上线。公开页面只展示职责、方法和验证状态，不伪造内部指标或系统截图。
07
证据链接
- 项目证据上线状态与职责说明可公开摘要
- 交付证据内部 SPEC、代码与联调记录保密
08
完整复盘
项目概述
这是一个面向 Agent 知识与策略配置的平台类项目。我的工作重点不是停留在原型层，而是将产品需求转化为清晰规格，并通过 AI Coding 参与可运行功能的完整交付。
痛点机会
配置类平台需要同时处理业务表达、交互效率和工程约束。如果需求、规则和页面行为缺少统一规格，产品方案很难稳定进入开发与验证阶段。本案例仅讨论公开的产品与 AI Coding 工作方式，不披露具体业务规则和内部系统信息。
目标指标
项目目标是建立从需求拆解到功能上线的清晰链路：形成可评审的产品与交互方案，将关键行为写入结构化规格，并让规格能够持续指导前后端实现、联调和验收。
方案设计
我采用 SPEC 先行的方式梳理页面目标、用户操作、状态变化和异常边界，再与 Coding Agent 协作规划实现步骤。AI Coding 在这里不是一次性生成原型，而是围绕明确规格持续完成实现、验证和修正。
落地推进
我负责相关功能的需求拆解与交互设计，并参与 JavaScript 前端、Go 后端功能实现。实现过程中与研发、QA 协作完成联调测试、问题定位、Bug 修复和部署上线，确保产品方案与最终行为保持一致。
效果复盘
相关功能完成开发、联调和上线，并沉淀出一套以产品规格驱动 AI Coding 的交付方式：先明确问题和边界，再生成与审查实现，最后通过测试闭环验证。出于业务隐私，本页面不展示内部指标、规则、代码或系统截图。
迭代反思
AI Coding 的价值不只是提高编码速度，更重要的是缩短产品判断与功能验证之间的距离。实践中，清晰的规格、持续的结果检查和对异常情况的显式处理，决定了生成代码能否进入真实交付链路。
隐私说明：本案例仅展示可公开的产品职责与 AI Coding 工作方式，不包含内部业务逻辑、效果指标、代码或系统资料。