适合
- 有明确负责人、真实流程和验收标准的企业
- 需要产品管理、询盘、报价、内容、图片或内部知识工具的团队
- 愿意分阶段试点，而不是一次性堆满功能的项目
Software / internal tools
软件开发与内部业务工具
当通用软件确实无法匹配关键流程时，再把需求做成可验收的软件。AI 可以加快研究、原型、测试和文档，但不会替代需求判断、安全边界和人工验收。
Fit & problem
这项服务适合谁，先解决什么。
优先解决
- 需求只是一长串功能，没有目标和非目标
- 数据、权限、异常、备份和维护在开发后期才被发现
- 项目上线后无人负责，无法交接或迭代
Deliverables
交付的是可检查的资产和工作方式。
需求诊断、范围表与交互原型
分阶段开发、测试和验收记录
部署、权限、日志、备份与回滚说明
操作文档、管理员培训和维护边界
Delivery flow
从范围确认到验收与交接。
诊断
确认业务结果、当前流程、使用者、数据和不能做什么。
原型
用低成本原型验证信息结构、主要路径和验收口径。
开发
按里程碑实现、测试和演示，变更进入范围记录。
上线
完成部署、权限、安全基线、培训、回滚和交接。
Commercial scope
价格必须和范围放在一起看。
公开价格是标准范围参考，不把后续新增功能、第三方费用和长期运营藏在模糊口径里。
一对一定制
诊断后范围报价先完成付费或约定的需求诊断，再给阶段、周期与报价。
- 范围和验收定义
- 原型与技术评审
- 分阶段开发测试
- 部署、文档与交接
Responsibilities & boundaries
客户配合与不包含内容提前说清楚。
客户需要配合
- 业务负责人持续参与
- 提供合法且必要的测试数据与账号
- 按节点评审并记录变更
- 指定上线后的系统所有人
默认不包含
- 未确认需求下的固定总价与固定周期承诺
- 未列入范围的新模块、长期运维和 24 小时响应
- 绕过平台权限、抓取私有数据或未经授权测试
- 把 AI 生成代码直接当成已验收成果
Evidence, not invented cases
当前能公开的能力证据。
未取得公开授权的客户项目不会包装成成功案例；以下只说明已验证的系统能力和边界。
已完成公开资讯、游客论坛、下载工具与 WordPress 运营后台等不同形态的本地项目验证
交付强调数据边界、发布门禁、可回滚和人工终审
客户项目只有取得授权、完成脱敏和证据核验后才会公开
FAQ
签约前常见问题。
可以只做一个小工具吗？
可以。只要目标、输入输出和验收清楚，小工具通常比大系统更适合作为第一步。
后续维护怎么算？
缺陷责任期、系统监控、依赖升级、服务器运维和新增需求会在报价中分开写，不默认无限维护。
Next step
填写咨询摘要 →把真实问题写成一页摘要，再判断是否合作。
先说明企业与行业、当前流程、主要问题、期望结果、负责人和时间。不要提交密码、Token、客户名单或生产数据。