普通任务管理主要回答谁在什么时候做什么；AI 编程项目管理还必须回答：智能体可以相信哪些上下文、获准改变什么、什么证据才算完成，以及下一次运行怎样安全继续。如果这些问题已经被仓库和现有流程解决，就继续使用原来的任务管理器；否则应补上一层执行契约，而不是为了 AI 重新做一套规划系统。
普通任务管理器擅长什么
看板、列表和 Issue 很适合管理优先级、负责人、依赖、截止时间和团队可见性。当人能够读完短任务，自行补齐上下文，做出判断并汇报完成时，它们依然是正确工具。
不要因为用了 AI 就抛弃熟悉系统。轻量的智能体工作流完全可以继续引用原 Issue 或路线图项。
智能体执行时多了哪些问题
智能体无法稳定猜中所有未写出的约定，因此需要清楚的执行契约：
- 上下文： 与任务相关的文件、决策、日志和当前状态。
- 权限： 可以查看、修改、提交、部署，还是写入外部系统。
- 边界： 哪些产品行为和用户工作不能碰。
- 证据： 哪些测试、渲染结果、投递状态或观察能证明完成。
- 继续： 下一次运行如何接手，而不必重建全部故事。
VS Code 的智能体概览显示，智能体能够规划、编辑、运行命令和使用工具。正因为能力更强，任务周围的权限与证据就比普通提醒事项更重要。
比较交接质量，而不是比较看板
拿一个真实任务检查：全新的智能体会收到什么？对于参加过会议的人，一张带标题的卡片可能足够；智能体通常还需要当前文件路径、任务背后的决策、受保护约束和准确验收检查。
再看任务返回了什么。“已完成”不如明确的差异、测试结果、上线地址与剩余风险说明。可直接使用编程智能体交接清单作为标准。
什么时候普通任务管理器已经够用
如果任务短、上下文容易恢复、改动风险低，而且同一个人从头跟到尾，就保留现有系统。先增加仓库指令和一致的任务模板，再决定是否需要新工具。
偶尔生成代码或全程有人监督的小修改，通常不需要复杂执行层。
什么时候值得增加 AI 执行层
如果你经常隔几天继续项目、同时运行多个智能体或项目、需要可审计边界，或总在重建上下文上浪费时间，执行层才开始产生价值。OpenAI 的 harness engineering 实践说明，让仓库知识和反馈变得清晰可用，是系统能力的一部分，不只是提示词技巧。
应根据返工是否下降、已验证结果是否更快来评估这层工具，而不是看它展示了多少智能体对象、状态或仪表盘。
SoloMap 处在什么位置
SoloMap 是本地优先的 VS Code 路线图工作台，不是通用企业任务管理器。路线图步骤、Solo 任务、项目记忆和带证据的交接都靠近仓库；你可以从相关上下文启动自己选择的本地智能体 CLI。它适合真正缺少“意图到执行连续性”的独立开发者。
外部 Issue 系统可以继续承担协作，SoloMap 则承担本地执行契约。边界说明见 SoloMap 方法论，项目组合视角见独立开发者如何管理多个副项目。
常见问题
AI 编程项目管理会替代 Jira、Linear 或 GitHub Issues 吗？
不一定。它们可以继续作为规划和协作系统；AI 执行层只需为选中的工作补上本地上下文、权限和证据。
一个人开发的最小配置是什么？
一份小路线图、持久的仓库指令、带边界的任务说明和可重复验证就够了。只有看到反复发生的连续性问题，才继续加工具。
智能体的每个动作都要变成任务吗？
不需要。应跟踪用户相关的结果。工具调用和中间推理通常只是执行细节，除非它们产生了必须审计的风险或证据。