2025/10/10 周五
打算用 RooCode 这个工具来协助开发这个 SSV 插件。找了 2 篇文章，先看看别人是怎么做的。
这里有一篇思源笔记插件开发的教程：插件开发入门 | 思源社区文档，这是一份官方的教程，内容有点多，需要发点时间来学习才行。
这里有一篇别人用 cursor 开发思源插件的教程：我是如何运用 cursor 一步一步开发思源插件的 - 少数派，这篇文章提供了一个完整的推进步骤，可以参考。
大致推进步骤就是，项目构思 → 查找资料和现成项目 → 部署环境 → 开发 → 完善，就按这个步骤进行推进吧。
项目构思，不知道项目构思需要写些什么，我采用的应对方法是 我先按自己的想到写一份，然后让 RooCode 帮我完善一下吧。姑且 LLM 用两个来对比一下 Deepseek V3 和 GLM4.6 吧。
2025/10/16 周四
工作上有事抽不开，今天继续回来这个主线任务。
我打算先自己初部写一个构想，然后再让 RooCode 帮我完善，然后我再确认和修改这个完善版。
初步构想如下：
- 这是一个思源笔记的插件
- 做这个插件的背景是，我已经在思源笔记中实现了 GTD 系统了，每一页笔记就是一个 stuff，每件 stuff 内会详细记录 stuff 描述/完结条件/推进情况。推进情况就是类似日志一样的流水账记录，这个对我用来回顾 stuff 推进情况是非常重要的。
- 痛点，这套基于思源笔记的 GTD 系统需要再完善的地方，也就是做这个插件理由。每件 stuff 里面，我会给自己做一些日程目标或者把一些结果反映在日程上，但是现在这些信息都零散分散在日志内，对于一些周期型 stuff，或者在制定协调 stuff 推进日程感的时候，需要一个能把目前我正在推进 stuff 的日程全部放到一个类似于按日为单位的日历中，这个日历的日期是从左到右的时间顺序，类似于表格的第一行，然后表格的第一列就是各个推进中的 stuff，而由（stuff，日期）交汇的格子就是这一件 stuff 在这一天的日程情况。
- 这个日程，我把他命名为 StuffScheduleView，他能单独在窗口中记入内容后自动记入日程内容到 stuff 详细侧，也能通过 stuff 详细侧通过某个标签来记入想要在日程侧展示的日程内容。
马上就遇到了问题了，我应该怎么判断后续用哪个模型呢？我为什么一开始想要用两个模型进行对比呢？不知道，我目前没想出来，先按下记工作流把终版的构想做出来先吧。
起码目前先有了一个终版构想：StuffScheduleView 插件设计构想.md
然后用这个构想书让 RooCode 规划一下吧。感觉需要提示一下插件开发的技术性资料给 AI 才能很好地规划，先把插件开发入门 | 思源社区文档 这篇文章转成 md 格式放到项目内容，并提示 RooCode 记得参考吧。虽说是规划，究竟是做什么出来我目前是不知道。
麻烦基于【StuffScheduleView插件设计构想.md】规划一下整合项目，关于插件开发的基础内容麻烦参考【思源笔记插件开发入门.md】
使用的模型是 GLM4.6，虽然一直以来使用的是 DeepSeek-v3，这次就用一下这个新模型吧。这么说来，我为什么用三个不同模型来实现构想呢？搞不懂自己为什么要怎么做，是什么样的直觉吗？还徒增了两份的 Token 消耗，后面就只用一个模型吧。今天完成了构想的确认，明明只有 1010 个字，我却确认了 4 个小时，中途睡着了 2 次。
2025/10/19 周日
RooCode 生成了三个文件【StuffScheduleView 项目规划.md】【技术架构设计.md】【开发指南.md】
仔细看了一下目前有的 6 个文件，我自己写的【初步构想】【StuffScheduleView 插件设计构想.md】【思源笔记插件开发入门.md】和 AI 生成的【StuffScheduleView 项目规划.md】【技术架构设计.md】【开发指南.md】
| 文件名 | 生成方 | 概要内容 | 类比 |
|---|---|---|---|
| 初步构想 | 我 | 描述插件背景、GTD 系统现状、核心痛点、期望功能（日历视图 + 双向同步）和命名 | 公司老总：提出战略方向、业务痛点与愿景，但不涉及具体执行细节 |
| StuffScheduleView 插件设计构想.md | AI（基于初步构想） | 将原始构想转化为结构化产品方案，包含视图布局、交互方式、数据格式（#schedule 标签）、同步机制、UI 草图、成功指标等 | 研发中心部长：将老板的战略转化为产品蓝图，定义“做什么”和“为什么做”，但不规定“怎么做 |
| 思源笔记插件开发入门.md | 思源官方文档 | 插件开发的基础知识、环境搭建、样板工程、入口机制、前后端 API 说明、调试与发布流程 | 外部顾问/行业标准手册：提供通用开发规范和平台约束，相当于“行业法规”或“技术准入标准“ |
| StuffScheduleView 项目规划.md | RooCode | 详细拆解开发阶段（四阶段）、MVP 任务清单、技术选型、目录结构、数据模型、API 策略、测试计划、风险评估等 | 研发中心科长：制定项目路线图、任务分解、资源分配和里程碑，聚焦“分阶段怎么做” |
| 技术架构设计.md | RooCode | 定义插件的分层架构（入口/数据/服务/视图）、数据流、状态管理、性能优化、错误处理、扩展性设计等 | 高级架构师 / 技术组长：设计系统骨架、模块职责与协作机制，确保可维护性与可扩展性 |
| 开发指南.md | RooCode | 提供具体编码规范、文件结构说明、组件示例代码（如 Schedule.ts、CalendarView.svelte）、测试写法、调试配置等 | 一线研发人员：执行具体编码任务，关注“每一行代码怎么写”和“如何验证功能” |
虽然是以“职能主导型”来进行项目推进（即部长就是项目总工）的类比，和自己熟知的“矩阵协同型”有点不同，不过就先这样吧。对于项目来说那种推进方法，需要的基础资料都一样。也许像【思源笔记插件开发入门.md】【开发指南.md】这类详细的内容，就是实际的实现层面的内容，虽说是不可或缺的，但是在我现在的这个规划阶段来说，不需要太多，能够指导项目大方向就可以了。
从资料的完备性来看，项目目标，用户场景，开发流程，阶段划分，技术分层还差一些资料。这些资料都需要什么内容？下个星期再完善一下吧。
仔细看了内容，还是觉得和我常用的 DeepSeek-v3 的输出还有有点不同的，所以我后面还是集中使用 DeepSeek-v3 和 Qwen3-max 吧。
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于