跳转至

讨论-记录-开发-测试循环

这个项目后续采用交替迭代方式推进：

讨论 -> 记录 -> 开发 -> 测试 -> 复盘 -> 下一轮讨论

这不是单纯的项目管理节奏，而是 Harness 的自试用机制，也就是“研用测一体”：研究方案、使用系统、测试效果在同一条闭环里发生。我们在开发这套系统的同时，也用这套系统处理自己的资料、讨论、实验和决策；当流程暴露问题时，再把问题作为产品迭代输入。

这也是当前 Framework 的核心能力方向：把 Loop Engineering 做成可复用的团队工作系统。不是让 Agent 无限自动跑，而是让每个循环都有目标、状态、工具动作、验证、持久化、退出条件和人工接管点。

当前项目里的 Demo、benchmark 和 case study 优先来自真实协作中暴露的问题，而不是为了演示临时编造。真实问题进入项目时要先保留 Evidence 线索，再脱敏成 Ontology 对象、规则、Skill、Workflow 或实验制品，最后通过 Runtime Projection 变成可复跑的 demo、benchmark、case study 或 CI gate。

写入时必须同时说明三件事：真实来源是什么、脱敏边界是什么、工程验证目的是什么。报告和 fixture 只保留问题类型、触发条件、工程后果、复现入口和验证信号；不保留原始聊天全文、截图、临时链接 token、完整日志、完整 SHA、个人隐私或客户材料。

一旦真实问题已经被转换成 benchmark、conformance case、CI gate、Semantic Review item 或 task-skill feedback，就由这些结构化检查和 Review Queue 接管；除非出现新证据，否则不要继续回到同一个原始截图、邮件或聊天片段上反复处理。

更完整的闭环是：

资料/观点/问题
  -> capture 到 workspaces/variai/evidence/inbox 或 workspaces/variai/evidence/raw
  -> compile 到 workspaces/variai/knowledge/wiki、项目页或 ADR
  -> develop 最小实现或实验
  -> test / benchmark / smoke test
  -> review 结果、成本和风险
  -> publish 成熟内容到 workspaces/variai/site
  -> 暴露的新问题进入下一轮 capture

每轮讨论产物

每次讨论结束后，至少落下一个产物：

  • 新增或更新一页文档。
  • 新增一个架构决策记录。
  • 新增一个工具 schema。
  • 新增一个 workflow 草案。
  • 新增一个测试样例。
  • 新增一段原型代码。

不让关键判断只停留在聊天里。

工作流

  1. 讨论 明确问题、约束、备选方案和当前判断。

  2. 记录 先写入 Evidence 或 Knowledge；稳定结论再发布到 Site。

  3. 开发 对成熟判断做最小原型，例如 adapter、MCP 工具、workflow runner。

  4. 测试 用单测、集成测试、手工 smoke test 或 eval case 验证。

  5. 复盘 把测试结果、风险和下一步写回文档。

  6. 反向迭代 如果本轮协作暴露出知识入口、检索、路由、review、发布或成本问题，把它写回项目计划、风险验证计划或 ADR。

文档维护规则

  • 协作方式写入 workspaces/variai/site/collaboration/。
  • 产品和方案知识写入 workspaces/variai/site/knowledge/。
  • 架构判断写入 workspaces/variai/site/knowledge/decision-log.md。
  • 总体方向写入 workspaces/variai/site/knowledge/vision.md。
  • 系统分层写入 workspaces/variai/site/knowledge/architecture.md。
  • 工具接口写入 workspaces/variai/site/knowledge/connectors-and-mcp.md 或后续工具专页。
  • 流程设计写入 workspaces/variai/site/knowledge/workflow.md 或后续 workflow 专页。
  • 安全和权限写入 workspaces/variai/site/knowledge/governance.md。
  • 测试和质量写入 workspaces/variai/site/knowledge/evals.md。

开发维护规则

后续可打包代码建议放在：

framework/
  connectors/
  context/
  workflows/
  governance/
  evals/
tests/

文档先行不是为了拖慢开发，而是为了让每次开发都有明确边界。

自试用判断标准

  • 团队成员丢给 Agent 的资料是否被保留了来源和上下文。
  • Agent 是否能把讨论编译成可复用的 wiki、ADR、测试样例或开发计划。
  • 网站是否能及时反映已经稳定的结论。
  • 每次实验是否记录效果、成本、失败模式和下一步。
  • 流程中的人工重复动作是否被沉淀为脚本、模板、workflow 或后续产品能力。