如果用一句话概括 Mira 的九月，我会选择：稳中向好，但速度仍然偏慢。
八月底，我们给九月定下的方向并不复杂：Mobile 逐步稳定，Desktop 开始落实下一阶段产品草案，同时减少依靠高强度推进来换取短期进度的开发方式。这个方向没有发生根本变化，真正值得记录的，是 Mira 的开发方式开始明显走向组织化。
从项目协作走向组织协作#
随着 Desktop、Mobile、Docs 和相关基础设施持续扩展，单纯依靠聊天记录、个人记忆和即时沟通维持开发上下文，已经越来越难以支撑实际工作。
九月开始，我们进一步明确了任务、实现、Review 与验收之间的关系，并逐步把 Issue 作为工作的主要契约载体。一个任务为什么存在、需要解决什么问题、边界在哪里、什么状态可以认为完成，开始有了更加明确和持续的记录。
对于目前规模仍然很小的 Mira 来说，这套机制看起来甚至略显正式，但月底 Mobile 的一轮集中开发证明，它并不是为了“建立流程”而建立流程。当维护者需要在不同功能之间补位，并连续提交较多改动时，明确的任务边界、Review 机制、分支环境和验收要求，为开发质量提供了实际保障。
因此，九月最重要的变化不是某一项制度本身，而是 Mira 开始逐渐拥有一套可以被多人、多个 Agent 持续理解和执行的工作方式。
Issue 变成真正的任务合同#
如果只能从九月的治理变化里保留一个东西，我们会保留 Issue 任务卡。
原因很简单：Constitution、Project Status、AI Review 和环境分支都很重要，但这些机制最终仍然需要围绕一个清楚的任务合同工作。Issue 负责把“我们准备做什么”固定下来，也负责把边界、非目标和验收条件暴露出来，减少实现过程中不断重写问题的机会。
这同样改变了 Agent 的工作方式。过去，Agent 很容易从一段聊天里推断出自己认为合理的下一步；现在，它更应该围绕一个具体、可检查的工作项施工。组织规则的意义，不是让每一步变得更慢，而是减少做完以后才发现“大家理解的根本不是同一件事”的返工。
Mobile：从功能验证走向产品建设#
九月 Mobile 的工作可以概括为三个方向：Agent、拾言和设置基础设施。
Agent 仍然是 Mira 核心体验演进的重要方向。拾言的产品定位也逐渐清晰：它更适合作为 Mira 的插件能力存在，而不是成为新的产品主线。插件可以针对具体场景提供更深入的能力，同时保持 Mira 本体的产品边界和一致性。
另一个重要变化来自设置相关基础设施。Memory、安全、存储、通用设置、通知等能力本身并不显眼，却是应用从功能演示走向长期使用必须补齐的部分。一个真正可使用的产品，不只需要核心功能，还需要让用户理解系统状态、管理数据和配置自己的使用方式。
月底另一位维护者的一轮集中补位，让这套组织化方式得到了实际检验：更新密度明显提高，但任务边界、Review 与验证没有因此被丢掉。对于一个规模很小的项目，这比单纯增加功能数量更重要。
九月 Mobile 还开始把 SonarCloud 纳入质量检查。它不会直接带来新的用户能力，但能持续暴露代码异味和安全门问题，让人工 Review 更集中在真正需要判断的地方。对 Mira 来说，这也是从“人和 AI 看起来没问题”向持续质量控制迈出的一步。
Desktop：草案没有问题，实现需要重新审查#
九月 Desktop 原本承担了更加明确的产品推进任务。围绕 Planner、Artifact、Workspace 和 Agent 等方向，我们已经开始落实前期草案，并完成了一部分基础建设。
但在第一阶段实现进入真人烟测时，我们发现了一个需要认真重新审视的问题，其中最典型的是 Conversation Workdir。
仓库中的既有设计已经存在 ChatWorkspace / Workspace 概念，而第一阶段实现又建立了一套 Conversation Workdir 的独立所有权、生命周期和 Artifact 关联机制。从工程内部观察，这套实现可以保持自洽，甚至拥有完整的契约和验证路径；但当真人尝试按照实际产品方式使用它时，问题很快暴露出来：用户为什么需要同时理解 Workspace 和 Workdir？
更值得警惕的是，烟测过程中甚至出现了通过特定自然语言来触发、确认 Workdir 行为的测试方式。这样的测试可以证明内部实现存在，却不能证明用户会自然地得到想要的效果。
因此，Desktop 第一阶段需要重新审查。
这里需要强调：需要重新审查的是落实方式，而不是产品草案本身。 下一步不应该继续增加新的工程抽象，而应该重新确认这些基础能力如何形成用户能够自然理解和使用的产品体验。
契约正确，并不等于产品正确#
八月开发回顾中，我们曾经总结：
AI 可以施工，但不能给自己签字。
九月的实践让这条经验又向前走了一步：
契约正确，也不代表产品正确。
任务卡、测试、Review、类型系统和生命周期约束，可以显著减少工程错误，但它们主要回答的是“实现是否满足了已经定义的要求”。
产品还存在另一个问题：
这个要求最终形成的东西，是否真的符合用户需要？
Workdir 的案例表明，AI 完全可能在工程约束内完成一套逻辑完整、测试充分、内部自洽的实现，而最终结果仍然不符合正常用户的认知和使用路径。
因此，未来的验收除了检查契约是否满足，还必须增加对“人类最终效果”的判断。这不是削弱工程规范，而是承认工程规范无法代替产品判断。
重新理解真人烟测#
九月也暴露了另一个问题：我们过去虽然不断强调真人烟测，但对真人应该在什么时间介入，还缺乏足够清晰的边界。
真人烟测不应该成为 AI 无法继续定位问题时的默认退路。如果一个错误仍然可以通过日志、测试、代码和运行状态继续判断，就应该优先完成这些自动化或工程侧检查，而不是简单要求真人反复尝试。
真正需要真人出现的节点，是产品效果开始形成的时候。此时需要验证的并不仅仅是功能是否返回结果，而是一个不了解内部实现的人，能否自然理解入口、操作方式和最终反馈。
换句话说，真人烟测不只是验证：
“它能不能工作？”
还应该验证：
“一个正常的人会不会这样使用它？”
这会成为下一阶段验收机制需要明确补上的一层。
十月只做两件事#
十月不准备继续扩大目标，目前最重要的只有两件事。
第一，重新审查并继续落实 Desktop 草案。 重点是减少不必要的概念和内部抽象，让 Workspace、Artifact、Planner 和 Agent 等能力真正形成自然、统一的用户体验。已经发现认知偏差的部分，需要先修正，再继续向后推进。
第二，完成 Mobile 当前功能的系统测试。 Mobile 已经积累了足够多的功能，下一阶段的重点应该从继续增加能力，转向验证现有能力在真实设备、真实用户路径、异常情况和恢复场景中的可靠性。
九月让我们进一步确认了一件事情：开发速度不能只用提交数量或任务关闭速度衡量。如果一次实现最终需要重新拆解产品认知，那么之前获得的速度，很大一部分只是提前透支了返工成本。
真正有效的速度，是每一步都尽可能接近最终需要的结果。
结语#
八月，我们开始明确 AI 不能自己完成从开发到验收的闭环。九月，我们进一步建立任务、Review、环境和质量检测机制，并第一次比较清楚地看到了另一类问题：即使所有工程环节都按照约定运行，最终结果仍然可能偏离人真正想要的产品。
这是 Mira 从工程协作走向产品协作过程中必须经历的一步。
流程正在变得稳定，组织正在形成，Mobile 也越来越接近一个完整产品。Desktop 的问题则提醒我们，未来不能只检查事情有没有“做完”，还需要持续检查它最终被做成了什么。
九月的进度没有预期中快，但至少，我们对什么叫“做对”有了更明确的认识。
十月继续。
同一段九月，如果想看更个人、也更不正经的一版，可以读 Tomz.io 的《两个男人，也不能只靠心有灵犀》。
