摘要：上周末，我使用 OpenClaw 和 Codex 为客户构建并部署了一个 Power Apps Code App。该应用程序整合了运营、财务、供应链与物流、市场营销、健康与安全、现场技术人员、项目管理、技术团队及领导层等各方面的工作。
以下是我如何运用 Agent、提示词、GitHub Issue、Power Platform 和 Dataverse 实现这一目标的分步解析。
几年前，我曾撰文用通俗语言解释 Microsoft Power Platform，其核心概念至今依然成立：它能让您围绕人们实际工作的方式构建真正的业务应用。这听起来显而易见，但大多数内部商业软件的诞生并非如此。
多数情况下，真实的流程散落在五六个地方。这里有张电子表格，那里有个数据库，还有会议记录，一些埋在 Teams 或 SharePoint 里的文件，一个财务系统，一个现场工作流，以及一个“全知道”如何整合这一切的人。
这个客户的情况也是如此。他们迫切需要一套统一的内部运营界面——不是一个营销网站，也不是另一个存放链接的地方。而是一个能运行的 Power Apps Code App，让公司能看到状态、推进工作、找到已批准的资源，并防止跨职能工作不了了之。
那么，我是如何在一个周末内完成构建的呢？答案是从不写代码开始。
OpenClaw 是上下文层
第一步是 OpenClaw。
OpenClaw 是我日常使用的编排工具，因此它已经积累了数月有价值的上下文：电子表格、工作流笔记、会议与通话记录、项目历史、源系统笔记、粗略的流程图，以及那些在有人打开 VS Code 时通常已经消失的小决策。
这数月的上下文比任何单个提示词都更重要。
我使用 OpenClaw 将数据模式的第一个版本构建为 JSON，并用 Mermaid 绘制实体关系图。我还用它来分离主要的业务领域和工作流，确保应用程序不仅仅是一个页面集合。
这部分很容易被低估。
对于业务应用来说，界面通常不是最难的部分。难的是界定工作的实际内容、数据的存放位置、数据的所有者、查看权限，以及在多个部门处理同一流程时，“完成”的定义是什么。OpenClaw 帮助将这些混乱的上下文完整地传递了下来。
OpenClaw 将混乱转化为清晰。
Codex 是交付层
一旦应用架构清晰，我便进入 Codex，选择 GPT-5.5 并将强度设到“极高”。Codex 的第一个任务也不是编码，而是设计规范。
我给 Codex 提供了一个我喜欢的网站作为视觉参考，以及客户营销团队的设计语言文档。我不希望它复制别人的产品、Logo、截图或模板资源。我希望能将有用的部分转化为规则：密度、导航、外壳行为、排版、颜色、表格、卡片、浅色模式、深色模式及响应式行为。
这些规则最终形成了一份设计规范 Markdown 文件。
我还让 Codex 使用了从 Claude Code 引入的 Frontend Design 插件。这有助于避免设计风格滑向那种常见的通用管理后台界面。你懂的——大卡片、模糊渐变、毫无密度可言，而且看起来总像是为某个虚构的 SaaS 公司制作的、用于销售仪表盘的仪表盘。
这个应用需要给人一种运营工具的感觉。
之后，我添加了 Power Platform 和 Dataverse 的 MCP、CLI 以及 Power Platform 技能。这一点至关重要，因为 Power Apps Code Apps 并非普通的 React 应用。它们具有 Power Apps 主机行为、生成的连接器模型和服务、Dataverse 约束、环境定位、身份验证假设以及部署规则。
如果 Agent 不事先了解这些约束，它会愉快地规划一个看起来很美好但在本地才能运行、一旦接触平台就会失效的方案。
/plan 环节
然后我使用了 /plan。这可能是整个周末最具杠杆作用的环节。
我让 Codex 阅读了仓库、参考导出文件、模式 JSON、Mermaid ERD、设计规范以及关于 Power Apps Code Apps 的 Microsoft Learn 文档。目标不是开始实现，而是生成一份我真正信赖的项目需求文档（PRD）。
这份 PRD 涵盖了：
- 产品范围
- 数据源规则
- 文件夹结构
- 路由结构
- 应用外壳行为
- 业务单元导航
- Dataverse 所有权
- 访问控制
- 审计与修订历史
- 归档行为
- 交付顺序
- V1 版本边界
- 路线图边界
- 验证关卡
是的，看起来很多。确实应该如此。这是为付费客户构建的业务系统，而不是周末的 Dribbble 设计稿。
质疑环节
PRD 完成后，我使用 @mattpocockuk 的 grill-with-docs 技能来拷问这个计划。它提出了一些日后能救你一命的刁钻问题。例如：
- 我们是从参考工件重建，还是迁移旧源码？
- 每个工作流的真实数据源是什么？
- 当 PRD、模式 JSON 和 ERD 出现偏差时怎么办？
- 哪些路由是 V1 版本，哪些应保持为占位符？
- Dataverse 安全在哪里强制执行访问控制，而 UI 只是在辅助用户操作？
- 哪些部分需要明确的 Power Platform 审批？
- 哪些部分目前是真实的，哪些只是路线图上的规划？
- 等等等等……
这个环节在开始实现之前就收紧了 PRD，而恰好在开始实现之前，正是找出漏洞的最佳时机。
与我所有的规划工作一样，PRD 的目标是生成构建应用初始版本所需的所有 GitHub Issue，并且每个功能的完整上下文都保存在对应的 Issue 中。这样一来，我可以更高效地使用 /goal，或者将部分工作交给其他人。对于几乎所有事情，即使是技术和编码之外的项目，我都遵循着完全相同的工作流程。
PRD，搞定所有事情！不，我是认真的。
提示词应保存在文件中
在这个项目中最有用的习惯之一，就是将提示词保存为 Markdown 文件。不是“在聊天里写好提示词，希望以后还记得”。而是实际的文件。
例如：
1根据你工作目录中的所有上下文，2请为我提供此应用的 /plan 提示词，3并将其保存为 Markdown 文件。
然后：
1分析 PRD，并为我提供一个 /goal 提示词，2用于生成所需的 GitHub Issue（包含完整上下文），3以交付该应用。将提示词保存到 Markdown 文件。
这给了我一个规划提示词、一个 Issue 生成提示词和一个实现提示词，它们都存在于仓库中。
这看似小事，但却改变了工作流。提示词变得可供审查、可以重用、可以交给另一个 Agent、可以改进。最重要的是，项目不再依赖于只有一个人能理解的聊天记录。
确切了解我如何构建这个应用，将帮助我的队友及其 Agent 理解如何支持和改进它。
PRD 变成了待办事项列表
PRD 准备就绪后，我让 Codex 根据它来生成 GitHub Issue。
每个 Issue 都包含了构建相应模块所需的上下文：工作流意图、相关路由、可能涉及的文件、Dataverse 表、依赖关系、验收标准、非目标、验证步骤以及注意事项（哪些不该碰）。
这个过程真正的回报就在这里。
Issue 成为了交接单元。我可以高效地使用 /goal，或者另一个人或 Agent 可以接手单个 Issue，理解工作内容，而无需翻阅整个周末的聊天记录。
然后我让 Codex 编写实现阶段的 /goal 提示词。
该提示词指示 Codex：拉取当前仓库和追踪器状态，选取下一个未被阻塞的 Issue，创建分支，做出最小的有用 PR，运行指定的检查，打开 PR，修复失败点，合并准备就绪后合并，同步主分支，然后继续。
它还设定了护栏：
- 未经批准不得写入生产环境
- 未确认目标前不得修改 Dataverse
- 未经批准不得更改角色、团队或群组映射
- 不得在测试夹具、截图、日志、文档或 PR 文本中包含密钥或私有业务数据
- 不得仅仅因为未来可能有用而创建宽泛的抽象
最后一条很重要。如果你允许，Agent 很喜欢为想象中的未来构建东西。但我不会。
构建过程
实现从共享外壳开始：路由基础、业务单元切换、桌面侧边栏、移动端导航、搜索、提醒、帮助、主题切换、离线指示器和基于访问权限筛选的导航。
然后是数据基础：Dataverse 模式元数据、生成的 Code Apps 模型和服务，以及一个模式验证器，用于确保 PRD、JSON 模式和 Mermaid ERD 保持一致。
最终的 Dataverse 合约达到了 89 张表、1148 列和 156 个关系！而我没有手动创建任何一个——这一切都由 Codex 通过 Dataverse MCP 和 Power Platform CLI 完成。这绝对是颠覆性的改变。
之后，Codex 以 PR 大小的模块处理整个应用：营销请求接收与工作板、首页内容、受管资源、提醒、健康与安全、个性化与草稿、管理与支持界面、运营状态、化学品定价、财务数据摄入、账单准备就绪、供应商账单匹配、盈利能力快照、库存与利润控制、财务报告、技术团队项目视图、实验室样品生命周期、ICP 到 SAT 证据、水处理工作流、共享能源服务界面、授权全局搜索以及发布准备就绪。
对于验证，我使用了与工作内容匹配的检查：模式变更用模式验证器，应用变更用 lint 和构建，路由和行为检查用 Playwright，UI 工作用截图，Power Platform 部分用部署说明。
到第二天结束时，应用已经实现、合并并部署。
只有一个访问验证项保持开放状态，因为它需要在生产环境中进行代表性用户验证。这并非失败。这恰恰是应该被追踪的事情，而不是在庆祝胜利时被一笔带过。
为何能成功
分工很简单。
OpenClaw 承载业务上下文，利用我团队与客户团队数月努力工作的成果，去更好地理解他们的业务。
Codex 将这些上下文转化为文件、Issue、PR、检查和部署说明。
如果跳过 PRD，跳过生成 Issue，直接要求代码，我能否更快地得到第一个界面？当然可以。
但我会信任这样一个跨部门使用的真实客户系统吗？绝不可能。
应用本身很重要，但文档追踪也同样重要。现在，任何人都可以查看仓库，了解哪些决策已做出，哪些功能已上线，哪些已验证，以及哪些仍需关注。
这就是我对基于 Agent 的开发模式的期望。我为我的客户构建了这个应用。他们拥有它，而我的职责是在过去 6 个多月与我们的合作中，妥善管理他们的时间和投资。
不是魔法。不是感觉。只是在构建真实软件时，更好地利用杠杆，更好地保留上下文，减少细节遗漏。
如果我和我在 @DigitalMeld 的团队能做到，你也可以。你的流程和规划远比选择的模型重要。从小处着手，着眼大局。
