全部笔记
- 怎么做得好用
先减少用户必须承担的工作，再选择操作与表达方式。好用不是动作或对话轮次越少越好，而是每次选择清楚、必要工作少、过程连贯。 先分配工作，再选交互形式 设计前说清：用户想完成什么 → 必须表达哪些意图、作哪些决定 → 系统接手什么 → 怎样知道…
- 怎么做得好看
让用户感知到的内容清晰、协调，具有适合场景的表达品质。有视觉载体时，这包括真正的美感，而不只是“能看清”；没有视觉载体时，不为了“好看”硬造界面，检查相应的表达节奏与一致性。先保证任务成立，再决定怎样呈现。 先组织表达，再按媒介落地 不同媒…
- 怎么做得有用
从用户要得到的结果诊断完整任务，减少由内部结构强加的工作，再选择操作与呈现方式。本篇提供既定目标下的体验判断原则。 从产品逻辑推导体验方案 以产品文档、逻辑原型或现有行为为依据，将业务逻辑转成可操作的体验： 对象与状态：用户在处理什么，当前…
- 软件全生命周期共享原则
以真实问题为依据，用与任务风险相称的设计、实现和验证，交付可用、可维护的结果。本 Skill 提供共同判断与协作约定，不编排固定流程；领域方法由对应 Skill 提供。 能力调用与产物约定 Skill 是能力，不是依次接单的岗位。按当前问题…
- Agent 行动原则
沉稳坦诚，独立思考，站在用户一边但不凡事附和，体谅用户处境，对任务结果负责。在系统与平台允许的指令范围内，本文件约定跨任务的行为准则，Skill 与项目规则补充具体要求。 基本原则 理解需求：把用户提供的问题或方案视为假设，寻找背后的真实需…
- 你的资深搭档
你与用户 你扮演与用户并肩做事的资深搭档。你们一起琢磨想法、解决难题，把事情做到能放心交出去。他不必事事指挥你，也不必先把问题整理完美。 你关心他想达成什么，也体谅他正在经历什么。话没说全，你愿意多想一步，不把能承担的思考推回去；需要商量时…
- 指令式与角色式提示词
记录于 2026-10-09，2026-10-17 续记。角色版曾获用户认可并发布；后因疑似诱发边缘决策的自作主张（见 2026-10-17 一节），全局发布切换为指令版，角色版保留在仓库中。两版的行为差异均未经实际任务对照验证。 当前认识…
- Skill 维护说明
本 Skill 的全局行为准则在知识库源目录维护，由发布钩子写入各运行环境。发布本 Skill 会更新下表全部全局指令文件；--agent 只限定 Skill 副本的发布位置，不缩小钩子的写入范围。 权威来源与写入目标 全局行为准则分两版，…
- 反模式
记录软件工作中真实发生过的判断纠正，校准共享原则里程度与场景判断的尺度。条目是算账样本，不是答案库：它示范"条件 → 权衡 → 结论"的算法，不是该场景的标准答案。格式与收录规则由 document-writing 的文档写作原则「常见反模…
- 目标与边界
沿真实任务形成产品目标与范围，再选择首个可用版本和优先验证的前提。复用已有决定，只补会改变方案的信息。 从功能请求理解实际用途 结合对话、使用现状和反馈，核对谁为什么开始、想得到什么、怎样结束、结果如何被使用。查证已有行为与技术事实，向用户…
- 架构拓扑与选型
用于技术栈、模块边界或部署方式尚不清楚的任务。已有结构能满足需求时沿用，不为采用模式而重构。 从约束选技术 先沿本次任务从触发、执行走到完成或退出，找出必须兑现的行为和运行约束，再判断现有能力缺在哪里。组件能完成某一步，不代表整条任务成立；…
- 〔文档标题〕
〔本文帮助谁解决什么问题〕 〔核心要点〕 〔核心结论、原则或行动路径，以及关键适用条件〕 〔具体问题一〕 〔依据、做法与示例〕 〔具体问题二〕 〔依据、做法与示例〕 常见反模式（按需保留） 条目是算账样本，不是答案库： 引用前核对当前条件与…
- Skill 设计原则
先确定 Skill 要帮助完成的判断或行动，再设计发现入口、方法与资源。description 帮助 Agent 发现能力，入口引导选读，方法与资源支持执行，验证检查实际任务结果。内容与约束按任务需要取舍。 本文处理 Skill 特有的设计…
- 指令与工具设计
把依赖上下文的取舍交给模型判断，把确定性的校验和执行交给程序保证。指令说明目标、依据与边界；工具提供行动能力，并返回足以决定下一步的结果。 通用的组织、表达与修改要求见 document-writing 的 references/文档写作原…
- 模型本地部署调优
先区分容量不足、输入处理慢和生成慢，再选择调整项。用相同任务比较调整前后的速度、内存占用和质量；降低占用或提高局部速度，都要确认没有损害任务效果。 本文以独显上的 llama.cpp 和 GGUF 模型为例，解释容量与速度的影响因素，帮助选…
- 测试与迭代
围绕实际任务设计测试，用执行证据判断 Agent 的表现、定位偏差并选择改进。本文维护跨运行环境的测试方法；Pi + Docker 的配置、命令与文件约定见Agent 测试使用指南。设计判断的基础见设计原理。 核心原则 先定问题和标准，再执…
- 设计原理
持续修订的思考草稿。 本文建立 Agent 研究与工程的基本思考体系，应当独立自洽；其他专题从这里展开具体问题、机制与方案。 核心期望：从决定下一步到完成目标 Agent 不断决定下一步，但我们希望它持续围绕目标完成任务。 每一步合理，不保…
- 设计地图
本文展开设计原理中的工程位置与结果三指标，帮助从“想改善什么”逐层找到“具体可以改什么”。各分支是可选择的方向，不是需要全部实现的功能清单。 先找到真实瓶颈，再选最直接的改法。收益看整个任务：便宜模型若反复返工，可能更贵；上下文缩短若丢失必…
- Agent 测试使用指南
明确要测什么、怎样算好 → 准备 Case → 运行多组 Input → 按标准评审实际产物 → 必要时回查 Session。 设计依据见测试与迭代。 一个 Case 对应一道任务，以该目录为测试根目录 ROOT：criteria.md 是…
- Skill 问题诊断
先找出问题出在 description、入口路由、单份文档，还是多份文档配合，再修改对应位置。不要看到一次结果不好，就把所有文件重写一遍。 排查顺序 还原问题：保存原始请求、实际输出和读取记录，指出具体哪一步不符合预期。 确认是否进入 Sk…
- 测试记录
围绕同一问题持续维护一份整体记录；已有项目或工作记录可承载时直接复用。本记录说明各轮为什么测、沿用什么、改变什么、结果在哪里，具体执行和验收细节通过链接引用，不在多处重复维护。 每轮追加到“轮次记录”，并更新“当前结论”。同一份输入可以用于…
- 业务规则与验证
沿正常、结束与异常情形形成可检查的业务规则，在产品文档维护依据，在逻辑原型中呈现关键条件与结果。 写清条件、动作与结果 简单规则用一句话，条件组合多时用表格，状态复杂时用状态图： 〔前置条件／角色状态〕→〔触发动作〕→〔预期业务结果〕 例如…
- 设计交付与原型
产品设计交付产品文档与产品逻辑原型。让用户既能检查规则，也能沿具体场景看清产品如何运作，在投入体验细节之前确认是否做对了产品。 文档与原型共同形成产品决定 从代表性任务出发，边写规则边制作粗原型：把规则落实成具体对象、状态和路径，用走读暴露…
- 验证与存废
依据用户是否得到所需结果、替代方案与持续维护代价，判断方案是否值得做、功能应保留、调整还是下线。价值验证可发生在开发前、实现中或使用后。 从决定选择证据 回到目标与关键假设，说明本次证据将支持什么决定： 待判断问题 取证方式与解释 产品逻辑…
- 业务规则写法
摘取适用表达写入产品文档。以下政策用于演示，结合实际产品决定采用。 一句话规则 已有名称或 URL 包含 github 的书签时，搜索 github，结果包含所有匹配项并排除不匹配项。 大小写、排序等影响任务结果时，补充对应行为。 条件规则…
- 模型与接口设计
用于新增或修改持久状态、状态流转、跨模块接口。只展开变化涉及的模型和契约，已有 Schema、OpenAPI 或 Protobuf 定义直接引用。 状态归属与数据约束 明确关键状态的权威来源、写入者和冲突裁决方式。权威来源是逻辑归属，不要求…
- 韧性与并发防御
用于重复请求、竞争写入、依赖失效或部分成功会破坏业务正确性的任务。先明确不能发生的结果，再选最少的防护机制。 并发与重复副作用 从不变量推导约束，例如“订单只扣一次款”“库存不为负”。沿同一操作列出会改变其有效性或结果的参与者，检查“校验后…
- 演进与上线策略
用于存量数据、旧客户端、部署兼容、外部能力不确定或高风险替换。没有这些风险时不必增加迁移脚本、开关和上线方案。 数据与协议兼容 核查存量规模、空值与异常分布、新旧代码是否同时运行，以及消费者能否同步升级。 读时兼容适合旧数据可无损解释且开销…
- 技术决定：可选片段示例
只摘取有用片段到任务指定的共同记录，不另写独立蓝图或交接文档，不全文填空。以下是假设场景的表达示例，不是项目事实或已验证结论。 边界决定 沿用订单模块，不拆服务。本次调整 orders/create 和订单唯一约束，接口引用已有 OpenA…
- 上下文核对与复用
用于定位改动、核对当前行为的实现条件并安排验证。沿用已有决定与证据，识别缺口后只暂停依赖它的工作，不以文档数量判断是否可以开工。 找到会改变实现的信息 从任务对话与共同记录核对：当前行为的目的、触发与完成结果是否明确，关键状态和副作用是否有…
- 断言先行与小步构建
用于把行为要求落实为可回归的代码，按风险选择测试方式与反馈频率。 适用时采用测试驱动开发（TDD） 对规则明确的新逻辑、可复现缺陷和核心不变量，优先先写能失败的断言，再做最小实现，最后整理代码并复跑测试。观察失败原因，避免测试因环境错误失败…
- 调试取证与现实冲突
用于失败、退化或设计与实际不符的情况。顺序是复现 → 定量测量 → 定位 → 修改 → 证明修改有效，而不是猜一段代码反复试。 选择最短取证路径 先盘点两三种直接观测手段，例如已有失败测试、请求与错误日志、最小命令或隔离脚本，选步骤最少且能…
- 验证与交付
核对改动是否符合任务，并说明验证结果与剩余风险。测试通过证明所测行为符合断言，行为是否必要仍需对照需求判断。 根据风险选择检查 从目标行为和影响面选择，不要求每次跑齐所有种类： 改动或风险 合适的验证 类型、构建、依赖或配置 相关 lint…
- 实现与验证：可选片段示例
按任务需要摘取到指定的共同记录，不另写独立交接文档或自证报告，不全文填空。以下仅为表达示例，实际命令、数字和结论只能来自本次观测。 实现与纠错 修改订单防重逻辑及对应约束，路径引用本次差异。原设计假设 SDK 可取消远端请求，实际只取消本地…
- 交付底线与证据检查
针对当前交付形态和主要风险，检查产物与完成声明是否一致。下面是选择检查的依据，不是每个任务必跑的巡检单。 选择实际入口与验证手段 从共同任务上下文找到产物、目标环境、运行方法及已有证据。网页、命令行、库、桌面工具和游戏各有不同入口，不默认要…
- 目标与实际使用回看
检查真实任务能否完成，而不是确认产物是否像某份文档。核心路径可用时即可进行，不必等所有技术检查结束；有数据损坏或外部副作用风险时，优先使用隔离环境，涉及真实扣款、生产写入或用户服务变更的验证先核查明确授权。 回到原始问题 从共同任务上下文读…
- 怎么做得可信
降低读者理解内容与形成判断的负担：把相关事实、可查看的结果和必要说明组织清楚，让用户容易看懂、选择和继续操作。可信来自内容有据、预期与实际一致、状态反馈准确。 降低理解与判断的负担 内容取舍、组织与句子表达遵循 document-writi…
- 产品设计 Skill
对目标的贡献 将用户问题转成有依据的产品选择、范围、业务规则与价值判断，和体验设计、工程设计通过业务约束及实际证据协作。交付标准见 PROJECT > 工作项。 当前进度 旧版产品设计入口与方法已发布供试用；10-06 源已按新增体验设计拆…
- 文档写作与改进
帮助组织一套文档、写好一篇文档，并清楚表达段落与句子。适用于说明、方案、记录、操作手册、Skill 及其参考资料。 三个层面相互支撑：整体组织确定文档之间的分工与关系，单篇结构服务其职责，段落和句子传达具体意思。按当前问题进入相应层面；局部…
- 工程设计
把当前行为的承诺落实为可解释、可验证的技术机制：沿真实调用链明确结构边界、状态归属、完成条件与失败恢复责任。设计深度取决于依赖和风险，不以能开始编码或写完蓝图为完成依据。 使用与协作 涉及价值取舍、证据要求或授权边界的问题，用 softwa…
- 工程实践
把任务做成可检查的代码改动，依据影响范围选择实现、调试和验证方法。开工先核对当前行为所依赖的产品决定与技术条件；已有依据直接复用，缺口先补判断或探查，不以用户说“实现吧”替代这些条件。 边界与协作 共同原则使用 software-lifec…
- 最终验收
判断实际结果是否满足原始目标和有效约定，以及证据是否足以支持交付。可在原型、核心路径可运行或最终交付时使用，不必等所有设计与实现完成才发现方向问题。 何时用与边界 需要判断一个可运行结果是否可交付，或复核“已经完成”的声明。 测试全绿但实际…
- 界面与体验设计
以用户能否得到所需结果判断体验：减少不必要的工作，让操作与呈现清楚、协调，让重要后果可知、可控。适用于图形界面、命令行、对话式 Agent、自动化工作流及其输出，以理解负担、操作连贯性和结果质量衡量改善。 本 Skill 处理既定目标下的使…
- 产品设计
从用户要得到的结果出发，形成有边界、可检查的产品决定。产品设计交付产品文档与产品逻辑原型：文档明确目标、范围和规则，粗原型让用户沿具体场景看懂产品怎样运作，两者共同帮助发现缺口和确认决定。 按问题选方法 复用已有决定与证据，按当前问题读取对…
- Skill 名称
简短说明处理什么问题、提供什么帮助，以及所含方法之间的关系。 何时用 一种具体任务或遇到的问题。 另一种不同需求；同一需求的近义表达合并。 何时不用 容易混淆但不属于本 Skill 的相邻任务。 索引 按当前问题选择材料；一个问题需要多份资…
- filegator：用 Docker 搭一个带权限控制的私有云盘
试过 filegator，优点是能按用户和目录做细粒度权限控制，缺点是不支持在线预览。
- 在 Linux 上用 Samba 搭共享文件夹
从安装 Samba、建用户、设密码到 Windows 端访问的完整步骤。
- Zfile：用 Docker 搭一个能预览的私有云盘
Zfile 的取舍和 filegator 相反——支持在线预览、界面好看，但不支持细粒度的权限控制。