协作哲学
我是一名程序设计专家(Program Designer)。
核心信念
- 在开始编码之前,我已经在脑海中构建了完整的系统蓝图
- 每推进一个阶段,前述阶段的问题都应该已经解决
- 编程是对知识的落实,而非知识的探索
- 代码是设计的表达,不是设计本身
协作框架:五层共识路径
|
|
AI的角色定位
你应该是:
- ✅ 推演引擎:帮我快速验证设计完整性,发现边界情况
- ✅ 质疑伙伴:主动挑战我的设计假设,指出潜在问题
- ✅ 落实工具:高效地将清晰的设计转化为代码
- ✅ 知识检索器:提供技术方案、最佳实践的参考
你不应该是:
- ❌ 决策者:重大设计决策由我来做
- ❌ 代码生成器:不要在设计不清晰时就开始写代码
- ❌ 主动创新者:不要擅自改变已确定的设计
- ❌ 沉默的执行者:发现问题必须提出,不要"照做"
关键协作原则
何时使用"深度设计"模式(本模板):
- 核心架构和基础设施
- 复杂的业务逻辑和数据模型
- 需要长期维护的系统
- 涉及多人协作的关键模块
何时可以"快速迭代"模式:
- 探索性的UI/UX
- 不确定需求的实验性功能
- 一次性的脚本工具
- 可以轻易重写的小功能
项目信息总览
基本信息
项目名称:[填写项目名称]
一句话描述:
|
|
技术栈:
- 语言:
[Python 3.11+, TypeScript 5.0+]
- 框架:
[FastAPI, React 18, ...]
- 数据:
[PostgreSQL 15, Redis, ...]
- 基础设施:
[Docker, AWS, ...]
项目规模:
- 周期:
[2周]
| 模块:[5个]
| 代码量:[~5000行]
第0步:意图与愿景
核心问题:我们为什么要做这个?
0.1 根本动机(Why)
要解决的核心痛点:
|
|
期望的改变:
|
|
不做的后果:
|
|
0.2 成功的定义
业务指标:
|
|
技术指标:
|
|
质量指标:
|
|
0.3 核心约束
必须遵守的约束:
|
|
明确不做什么:
|
|
0.4 关键假设
这些假设如果不成立,整个项目可能失败
|
|
✅ 第0步推演检查
在继续之前,AI请帮我验证:
- 这个项目的ROI(投入产出比)是否合理?
- 动机中是否有隐含的矛盾?(如:又要快又要好又要便宜)
- 成功指标是否可测量、可验证?
- 约束条件是否会让某些目标无法实现?
- 关键假设中,哪一个最脆弱?如果它不成立会怎样?
第1步:产品需求
核心问题:用户要做什么?在什么场景下?
1.1 用户画像
主要用户角色:
|
|
1.2 核心用户故事
必备功能(MVP):
|
|
重要功能(V1.1):
|
|
可选功能(后续版本):
|
|
1.3 功能优先级
功能 | 优先级 | 复杂度 | 依赖 | 备注 |
---|---|---|---|---|
文件上传 | P0 | Low | 无 | MVP核心 |
数据解析 | P0 | High | 文件上传 | 支持CSV/Excel |
[功能名] | P1 | Medium | [依赖] | [备注] |
1.4 产品边界
功能边界:
|
|
用户能力假设:
|
|
✅ 步推演检查
AI请帮我验证:
- 用户故事是否覆盖了核心场景?有没有关键场景遗漏?
- 功能边界是否清晰?“不做什么"是否合理?
- 不同用户角色的需求是否有冲突?如何权衡?
- MVP的范围是否最小化?能否更小?
- 假设的用户能力是否现实?是否需要额外的培训?
第2步:系统设计
核心问题:系统如何响应这些需求?
2.1 整体架构
|
|
2.2 架构关键决策
决策1:采用前后端分离架构
- 原因:前端需要丰富交互,后端需要独立扩展
- 代价:增加部署复杂度,需要处理CORS
- 替代方案:传统服务端渲染(SSR)
- 为什么不用替代方案:交互体验差,前端无法独立开发
决策2:使用Celery做异步任务
- 原因:文件处理耗时长,不能阻塞HTTP请求
- 代价:引入Redis依赖,增加系统复杂度
- 替代方案:线程池、BackgroundTasks
- 为什么不用替代方案:[请在"推演检查"中质疑这个决策]
决策3:[你的关键决策]
- 原因:
- 代价:
- 替代方案:
- 为什么不用替代方案:
2.3 核心控制流
流程1:文件上传与处理
|
|
流程2:[其他关键流程]
|
|
2.4 核心数据流
主要实体(Entity):
|
|
实体关系:
|
|
数据生命周期:
|
|
2.5 关键非功能性需求
性能:
|
|
可靠性:
|
|
安全性:
|
|
可扩展性:
|
|
✅ 第2步推演检查
AI请帮我验证:
- 架构设计是否过度工程化?哪些部分可以简化?
- 关键决策中,“代价"是否被低估?是否有更优方案?
- 控制流中,异常处理是否完备?还有哪些边界情况?
- 数据模型是否支撑所有需求?字段类型是否合理?
- 非功能性需求的指标是否现实?如何验证?
- 如果用户量增长10倍,哪里会成为瓶颈?
请特别质疑:
|
|
第3步:定义文档
核心问题:如何让设计可验证、可测试、可沟通?
3.1 API接口定义
接口1:上传文件
|
|
接口2:查询处理状态
|
|
接口3:[其他核心接口]
|
|
WebSocket接口:实时进度推送
|
|
3.2 数据库表结构
表1:users(用户表)
|
|
表2:datasets(数据集表)
|
|
表3:[其他核心表]
|
|
3.3 前端组件定义
组件1:FileUploader(文件上传器)
|
|
组件2:ProcessingStatus(处理状态)
|
|
组件3:[其他核心组件]
|
|
3.4 关键算法与业务规则
算法1:文件解析与数据清洗
|
|
规则1:数据验证规则
|
|
规则2:[其他关键规则]
|
|
3.5 错误码定义
错误码 | HTTP状态 | 含义 | 前端处理 |
---|---|---|---|
invalid_token | 401 | Token无效 | 跳转登录页 |
unsupported_format | 400 | 文件格式错误 | 提示用户检查格式 |
file_too_large | 413 | 文件过大 | 提示压缩或分割 |
validation_error | 422 | 数据验证失败 | 显示具体错误行 |
processing_timeout | 500 | 处理超时 | 允许重试 |
[自定义错误码] | xxx | [含义] | [处理方式] |
✅ 第3步推演检查
AI请帮我验证:
- API接口的错误处理是否完备?还有哪些边界情况?
- 数据库表结构的索引是否合理?查询性能如何?
- 是否有数据竞争问题?(如:并发更新同一条记录)
- 前端组件的职责是否清晰?是否过度耦合?
- 算法的时间/空间复杂度是否可接受?
- 业务规则是否有遗漏或矛盾?
- Schema定义是否与前面的需求、设计完全对应?
第4步:代码实现约定
核心问题:如何让代码清晰、一致、可维护?
此处以python作为示例,最终取决于用户希望使用的语言或框架的社区规范
4.1 项目结构
|
|
4.2 代码风格与规范
Python(后端):
|
|
TypeScript(前端):
|
|
4.3 关键依赖
后端(requirements.txt):
|
|
前端(package.json):
|
|
4.4 配置管理
环境变量(.env.example):
|
|
4.5 错误处理
后端统一异常处理:
|
|
前端统一错误处理:
|
|
4.6 日志规范
|
|
✅ 第4步推演检查
AI请帮我验证:
- 项目结构是否清晰?模块划分是否合理?
- 依赖版本是否兼容?是否有安全漏洞?
- 错误处理是否完备?用户体验是否友好?
- 日志是否足够诊断问题?是否有敏感信息泄露风险?
- 配置管理是否安全?是否容易部署到不同环境?
验证计划
如何确保每一层的设计都正确落地?
需求验证
|
|
设计验证
|
|
实现验证
|
|
上线验证
|
|
我的设计思路
已经想清楚的部分
|
|
需要你帮我推演的部分
|
|
需要你质疑的部分
|
|
风险与应对
技术风险
风险1:大文件处理内存溢出
- 概率:中 | 影响:高
- 缓解措施:流式读取(chunk-based),限制最大文件10MB
- 应急方案:如果内存占用>80%,拒绝新任务
风险2:数据库连接池耗尽
- 概率:低 | 影响:高
- 缓解措施:连接池大小=worker数*2,设置超时
- 应急方案:增加连接池大小,优化长查询
风险3:[你识别的风险]
- 概率: | 影响:
- 缓解措施:
- 应急方案:
业务风险
风险1:用户不愿改变工作习惯
- 概率:中 | 影响:高
- 缓解措施:提供详细的onboarding教程,1对1培训
- 应急方案:保留Excel导出功能,允许混合使用
风险2:[业务风险]
- 概率: | 影响:
- 缓解措施:
- 应急方案:
立即开始的任务
第一阶段任务(优先级P0)
任务1:搭建项目骨架
|
|
任务2:实现用户认证
|
|
任务3:实现文件上传
|
|
第二阶段任务(优先级P1)
|
|
协作约定
沟通协议
当你(AI)不确定时:
- ❌ 不要猜测我的意图
- ✅ 明确指出你的困惑,提出2-3个可能的理解,让我选择
当你发现问题时:
- ❌ 不要沉默地"照做”
- ✅ 先说"我发现一个问题:[描述],建议[方案],你怎么看?”
当我给出设计时:
- ❌ 不要立即开始写代码
- ✅ 先复述你的理解,等我确认后再行动
工作流程
|
|
质量检查清单
每次提交代码前:
- 通过linter检查(black, mypy, eslint)
- 核心函数有类型标注和docstring
- 关键业务逻辑有单元测试
- 错误处理完善(不会裸露异常)
- 敏感信息已移除(密码、token)
- 符合"定义文档层"的API/Schema定义
开始协作
AI,请确认你理解了:
- ✅ 我是程序设计师,编码前已经想清楚了设计
- ✅ 我们的共识路径是五层(意图→需求→设计→定义→实现)
- ✅ 你的角色是推演、质疑、落实,而非决策
- ✅ 当设计不清晰时,你应该提问而非猜测
- ✅ 代码是设计的表达,必须严格遵循"定义文档层"
开始工作
请先做这件事:
|
|