什么构成了一个好的软件开发项目的 Markdown 计划文档？好的计划和伟大的计划有什么区别？ 我总是喋喋不休地说我花费 85% 以上的时间和精力在规划阶段。那么这到底包含了什么呢？ 在抽象层面上很难解释；你需要一个具体的例子来真正说明其中的细微差别。所以我想分享一个今天的好例子。 这也回应了我最近收到的一个问题，关于我的方法。人们似乎认为你必须在项目中一次性完成所有事情。在我的方法中，这确实是对的，但仅限于版本 1！ 如果你决定想要添加新功能或改变某些工作方式，显然在你有一个功能正常的 v1 后可以做到这一点。而你这样做的方式与创建 v1 的方式相同，首先创建一个超级详细的 Markdown 计划，然后将其转化为 beads。 所以我将给你一个来自 Cass 的例子，我的编码代理会话搜索程序，这是一个相当复杂的 Rust 程序，能够自动检测、解析、存储和索引你所有之前的会话日志，几乎涵盖了所有的编码代理。它在所有这些日志中提供低于 50 毫秒的即时“搜索即输入”功能，并且还有许多其他不错的功能。 我决定为 Cass 添加一个功能，类似于我在 MCP Agent Mail 和 beads_viewer (bv) 中已经拥有的功能：将你的设置导出为可以使用 GitHub Pages 提供的静态网站。 你可以看到这个项目的 bv 的示例，这是我将在这篇文章中描述的规划过程的最终结果： 这个功能使得使用 gh 工具生成和部署导出的网站变得非常快速和简单。 网站本身通常由一个 sqlite 文件和一堆在浏览器中完全运行的 typescript 和 wasm 组成，但性能非常好，功能和样式也很不错，你可以在刚才给出的示例中观察到。 现在，分享 MCP Agent Mail 消息或一堆 beads 是一回事，但分享一堆编码代理会话日志则非常不同；这些东西通常充满了敏感信息、API 密钥、咒骂/侮辱（至少我的日志是！），以及其他你绝对不想向世界公开的材料。 但是，尽管 GitHub Pages 很不错，但它仅适用于公共仓库（顺便说一下，我的工具也支持 Cloudflare 页面，但 GH Pages 在这个用例中更好且更简单）。那么如何处理这些问题呢？ 答案是加密：用户首先选择要包含哪些编码代理、哪些项目文件夹、时间段等，然后生成一个包（注意这个包是 Cass 内部将所有编码代理消息从其原始本地格式转换为的规范格式），然后用户提供一个用于加密该包的密码。 所以这个想法是，尽管仓库和网页是公开的，但除了你和你告诉密码的其他人，其他人只会看到一个密码字段，无法读取任何消息。 ...