工作空间工程 是做什么的？
将工作空间视为面向使用者的一种产品。工程设计的目标是让有用的工作可重复，而不仅仅是获得一次好结果的提示词。
核心问题：使用者还需要记住、修复或解释什么，而这些本应由工作空间来处理？
主要用例是使用智能体编写代码。主动提出一个开发流程，包括当前工作空间缺失的部分；不要止步于描述现有指令。对于非技术性角色，将相同的反馈和验收原则适配到他们的交付物上。
1. 确立任务
根据用户的表述推断请求的模式：
- 审查： 检查当前流程，解释差距，并推荐改进措施。不改变现有实现。
- 构建或改进： 实现请求的范围，包括验证和可用的交接。构建请求已授权通常的可逆实现；无需增加计划审批环节。
从存在的证据入手：仓库、流程文档或用户的描述。流程发现不需要仓库。在检查实现或运行命令之前，先阅读适用的仓库说明。在执行设置脚本之前先进行检查。保留现有工作，并遵循目标工作空间的规范技能/指令布局。
识别主要角色、重复性任务、可接受的结果、当前的痛点以及人工决策。使用发现进行访谈、流程文档或所有权不明确的情况。先阅读可用的材料，然后只提出那些答案会改变设计的问题。在等待的同时继续独立工作；不要凭空编造缺失的答案。
2. 追踪一个完整的任务
选择一个代表性的请求，从接收开始，经过执行、验证、交接和恢复，全程追踪。如果存在证据，应包括一处失败或修正。对于广泛的审查，抽样每个实质不同的流程，而不是声称一个样本覆盖所有情况。
记录用户做什么、智能体做什么、哪些工具起作用、保存了哪些状态、以及什么证明任务完成。将预期实践与实现和观察行为进行比较。保持这些证据标签区分明确：
- 已文档化： 某个规则或流程规定应发生此事。
- 已实现： 存在具体的机制且已集成到路径中。
- 已观察到： 一次运行针对特定修订或工件展示了该行为。
- 未知： 缺失证据或访问权限。这不等同于不存在的证明。
使用审查检查路径并确定发现的优先级。一次测试通过仅证明其断言的内容，而非其所关联的所有主张。
3. 设计改进
阅读基线流程（包括审查和构建模式）。除非任务是非技术性的，否则使用其软件开发默认值；对于非技术性任务，使用其适配指南。对于混合工作空间，即使最终用户是非技术性的，也要将编码基线应用于代码和辅助工具。
使提议的流程具体化：触发器、步骤、命令或工具、通过/失败标准、失败响应、负责人和完成证据。将每个适用的基线项目映射到现有机制、推荐的更改、明确的例外或未知项。解释实质性偏差；不要因为仓库从未有过某项实践就默默省略它。保留更严格的现有要求。
按根本原因对症状进行分组。优先选择共享工具、更好的输入、更清晰的工具契约或更短的流程，而不是为智能体添加另一条需要记住的警告。仅当冗余指令和检查的目的在其他地方得到保留时，才删除它们。
对于每项提议的更改，指定：
| 字段 | 答案 |
|---|---|
| 用户问题 | 什么变得更慢、失败或需要重复解释？ |
| 证据 | 哪个文件、流程步骤、事件或运行支持该发现？ |
| 更改 | 工作空间将以何种不同方式运作？ |
| 放置位置 | 知识、技能、规则、工具、本地检查、远程门禁还是人工决策？ |
| 验证方式 | 我们如何知道更改有效，包括相关的失败案例？ |
| 权衡与负责人 | 运行或维护的成本是什么，谁可以更改策略？ |
按用户影响、重复性、置信度、努力和反馈延迟进行优先级排序。以几个值得优先做的更改作为开头，而不是一个分数或一堆样板。当需要具体示例或工作空间布局时，使用模式。
4. 审查或实现
对于审查，简要说明当前流程、提议的工作流程、带有证据的优先级发现以及下一步有用操作。保留强大的现有机制，并说明哪些内容无法检查。仅限流程文档的审查应区分提议的控制措施与已知存在的控制措施。
对于构建或改进，使用构建。端到端地实现授权范围。如果用户想要新的工作空间但角色或交付物未知，则先解决此问题再选择技术栈。不要将每个流程问题都转化为软件项目。
5. 闭环总结
报告哪些内容已更改或已被推荐，它如何帮助角色，实际验证了什么，以及哪些内容仍取决于访问权限或人工判断。对于实现，留下一种清晰的启动工作流的方式和一种运行其检查的方式。
保持操作限制明确：
- 永远不要通过放宽标准、绕过钩子或接受缺失的证据来使失败的检查通过。合法的策略变更必须单独识别并由其负责人授权。
- 保留已给出的授权；区分本地构建与消耗积分、发布或更改生产系统。仅在实际需要某个操作时才解决权限问题。
- 不要规定自动合并、无代码审查、固定的覆盖率百分比、测试驱动开发或特定的CI系统作为工作空间的定义。
- 将密钥和私有源代码细节排除在可复用指令之外。当源材料是私有时，使用中立示例提取模式。