RDDSH 学习小组

DSH 学习小组 · 第一期周报 ​

2026 年 10 月 17 日｜创刊号

本期主题：如何正确地使用 AI——少许愿，多提炼。

来自不同专业领域的成员分享了各自在 AI 工具中的实践经验，包括软件开发、机械设计、内容创作与日常工作自动化。

即使应用场景不同，交流中也呈现出一个共同的问题：我们应该怎样使用 AI，才能真正提高生产力？

本周主题：少许愿，多提炼 ​

AI Agent 的能力正在快速发展。我们已经可以用自然语言要求它编写程序、操作软件、处理文件，甚至执行一整套工作流程。但工具能力的提高，并不意味着我们可以省略对工作的理解。

本周交流中出现了两个很有代表性的例子。

案例一：让 AI 帮忙剪视频 ​

假设我们希望 AI 完成一期视频制作。最简单的做法，是把素材交给 Agent，然后告诉它：「帮我剪一条视频。」

问题在于，这句话并没有说明真正的工作流程。

哪些素材应该使用？每段素材表达什么？脚本与画面如何对应？剪辑的节奏如何安排？这些原本由创作者完成的判断，不会因为交给 AI 就自动消失。

一种更可行的方式，是将已有的创作经验提炼成流程。

先为素材分类和标记，整理脚本，再将这些内容放入统一的工作区。Agent 可以根据脚本寻找对应素材，调用 FFmpeg 等工具进行裁剪与拼接，最后由人检查结果。

这不意味着 AI 已经可以独立完成高质量的视频创作。相反，我们是在尝试找出：哪些工作可以交给工具，哪些判断必须由创作者保留。

在这一过程中，Skill 可以记录创作规则，MCP 可以为 Agent 提供工具，而脚本则适合执行明确、重复的操作。

案例二：让 AI 复刻一个网页 ​

另一个案例来自实际的软件开发。最初的要求很简单：「按照这个网页，帮我复刻一个。」Agent 很快生成了一个外观相似的页面。但进一步检查发现，它只是一个静态界面。页面上看似完整的功能，并没有真正连接数据源。

于是，任务继续扩展：让 Agent 自己寻找数据、理解业务逻辑、补全计算过程。结果是大量反复尝试、较高的执行成本，以及始终无法可靠运行的程序。

问题并不完全在模型能力。一个网页的外观可以通过观察获得，但它背后的数据关系和业务规则，并不一定能从界面中推断出来。

后来，工作方式发生了变化：先明确每项数据的来源、计算方法及处理顺序，再让 Agent 按这些规则编写程序，并在关键步骤进行验证。

这要求使用者“强迫”自己掌握业务逻辑，却能显著减少没有方向的探索。与AI协作的过程，恰恰是梳理自己的过程

从两个案例中提炼什么？ ​

两个案例看似不同，实际上指向同一个问题。AI 可以替代一部分劳动，但不能替代我们对劳动过程的认识。如果我们自己也说不清一项工作是怎样完成的，那么一句「让 AI 帮我做完」，实际上就是要求模型同时完成需求分析、方法设计、专业判断和具体执行。这种方式可能偶尔成功，却很难稳定复用。

因此，本周我们提出一个简单的原则：

少许愿，多提炼。

少一些「帮我把这个全部做好」，多一些对现有工作方法的观察、拆解与整理。让 Agent 执行明确的任务，让 Skill 保存可复用的方法，让工具承担重复的操作，让人继续负责目标、判断与验证。

真正值得积累的不只是某次成功生成的结果，更是结果背后能够再次使用的工作方法。经验从实践中提炼，从实践中反思，投入到实践中去应用。

下一阶段：探索 AI 在专业工作中的应用 ​

小组的研究不会局限于软件开发，也不会局限于 DSH 本身。我们希望从成员已有的真实工作出发，寻找 AI 能够实际参与的环节，并将实践结果转化为可共享的经验。

工业绘图与 SolidWorks 将是下一阶段重点关注的方向之一。

机械设计与一般文本生成不同。零件尺寸、几何关系、装配约束及加工要求，都需要严格的专业判断。目前，社区已有一些尝试通过 MCP 将 AI Agent 接入 SolidWorks 的项目，也出现了面向机械建模的 Skill 和操作规则。这些工具是否足够可靠？能否完成真实的零件建模、修改和装配任务？如何把机械设计知识与 Agent 的执行能力结合起来？这些问题仍需要实际测试。

此外，小组也将持续关注自媒体制作流程自动化，以及 AI 在网络跨境电商等业务场景中的应用。我们的探索不以展示 AI 能做多少事情为目的，而是关注它能否在真实工作中稳定地完成任务。从这些任务中蒸馏提取通用的经验，惠及更多同行者。

小技巧：在 ChatGPT 网页版中使用 Team 工作流 ​

本周分享了一种轻量化的 AI 辅助开发方法：

ChatGPT 普通聊天 + GitHub Connector + Project Team Skill。

其思路来自 DSH 的 Team 模式：不让单个 Agent 承担整个项目，而是通过具有不同职责的角色协作。

如何运行？ ​

首先，在 ChatGPT Project 中建立一个 Lead 会话，负责需求讨论、方案规划、任务协调和结果整合。当项目确实需要独立的实现、审查或其他职责时，再建立对应的角色会话。角色不必预先固定，也不需要为每个新任务创建一个新会话。每个会话保留自身的工作历史。通过简短的 Handoff，将任务交给其他角色。

GitHub 则承担共同工作区的作用：各个角色可以通过 Connector 读取仓库、修改代码、查看 Issue 和 PR，并利用这些产物协调工作。

与 DSH 原生 Team 不同，这种方式没有自动唤醒其他角色、跨会话通信或共享任务调度能力。用户仍需手动切换会话并传递必要的任务信息。但它提供了一种值得尝试的替代方案：利用 ChatGPT 普通聊天环境完成部分开发工作，减少对独立 Agent 执行额度的依赖。

同时使用者扮演“传递者”的角色，让用户不至于完全成为“局外人”，可以根据handoff的进度，来做出及时的干预和调整。这也是我们主张的 通过AI学习，参与劳动，而不是成为AI的“甲方” 。

为什么使用 Skill？ ​

这里的 Skill 并不是另一套自动化调度系统。

它主要规定如何组织长期协作：

  • 从一个 Lead 会话开始，按实际需要增加角色。
  • 保留角色的持续职责和上下文，避免重复建立会话。
  • 通过 GitHub 中的真实产物维护项目状态。
  • 使用简短 Handoff 传递任务，而不是反复复制完整上下文。
  • 将实现与独立审查分开，避免角色自行批准自己的工作。

这既是对上下文管理方式的探索，也是对开发成本的一种优化尝试。

相关资源

DSH 学习小组开始试运行 ​

DSH 学习小组是一个围绕 AI Harness、Agent、Plugin、Skill 及自动化工作流开展交流的兴趣小组。小组不限定成员的专业领域，也不要求所有实践必须使用 DSH。

试运行期间，我们约定：成员每周通过分享、评论或参加会议等方式保持有效参与；鼓励分享实际工作流、技术问题及工具使用经验，并尽量将有价值的内容整理为文档；周会原则上安排在周末晚间，无法参加时提前说明；同时尝试利用 GitHub Issues 开展异步周会，降低时间协调成本；每周整理并公开发布一份周报，由会议主持人兼任编辑，逐步实行成员轮值与经验交接。长期不活跃成员将被移除小组。

我们希望建立一个怎样的社群？ ​

小组的成立，不只是为了交流新工具。在第一次会议中，我们提出了一种项目团队的组织思路。

传统项目往往围绕一项业务聚集成员。不同专业的人共同完成同一个目标，但跨项目、跨专业的经验交流不一定充分。

兴趣小组则尝试从另一个方向建立联系。成员可以来自不同职业、不同项目，有各自的业务目标，同时围绕共同的技术兴趣进行横向交流。

一项工作中形成的方法，可能对另一个领域同样有帮助。例如，机械设计中的流程拆解、内容创作中的素材组织，以及软件开发中的上下文管理，都可能形成可迁移的方法。

我们希望通过这样的交流，让个人经验不再局限于各自的工作环境。同时，我们也希望检验一种小规模、高活跃度、低参与负担的协作方式。成员不必每周准备正式报告，也不需要持续投入大量时间。一次真实的问题讨论、一段工具使用经验，或者一个经过验证的小技巧，都可以成为有价值的分享。

但这些交流不能只停留在聊天记录中。通过会议纪要、异步讨论与周报，我们希望逐渐建立一套可以检索、引用和再次使用的公共知识记录。更长远地说，小组的目标是探索一种能够跨越具体项目、持续促进成员技术成长的协作关系。