Wubuntu Tech & Life

关联文档：[[acw/blog/004 一个最小可用工作区|一个最小可用工作区]]、[[acw/blog/007 真正值得沉淀的，是高质量中间产物|真正值得沉淀的，是高质量中间产物]] 最终产物只是一次结果 过去做一件事，我们最关心的是最终产物。产物当然重要，因为它直接解决问题，也决定一次任务有没有完成。 但进入 AI 时代后，我越来越确定：更值得长期积累的，是那套能够持续生成产物的系统。它可能是一组指令、一套规范，也可能是一个组织良好的工作区。 最终产物解决的是“这一次交付什么”，生成系统解决的是“下一次能否更快、更稳定地交付”。前者创造当下价值，后者决定价值能否复利。 如果一篇文章只能依靠漫长对话偶然写出来，那么换一个对话、换一个模型，许多背景和判断都要重新解释。相反，如果选题定位、读者画像、写作规范和审校标准都已经沉淀，文章就不再是一次性的答案，而是一个可重复运行过程的结果。 为什么传统工程目录不够 以软件开发为例。过去我们创建一个 my-code/ 目录，把源码、配置、测试和构建脚本放进去。现在常见的做法，是让 AI 直接进入这个目录阅读和修改代码。更进一步，有人会添加 docs/ 或 ai/ ，专门保存需求、提示词和沟通记录。 这种方式能工作，但 AI 所需的上下文仍是附属信息。面对大量源码和工具配置，它未必能立即判断：项目为什么存在，当前目标是什么，哪些规则必须遵守，以及这次任务应该如何验收。 问题不在于 AI “看不懂代码”，而在于代码只能描述系统现在如何运行，不能完整解释系统为什么这样设计。许多关键知识散落在人的记忆、聊天记录和历史决策中。AI 能读取文件，却无法自动补全这些缺失的上下文。 因此，AI Native 并不是多建一个 ai/ 目录，而是重新安排信息的主次关系：先让 AI 获得完成任务所需的背景、规则和路径，再让它按需进入代码或其他项目文件执行工作。 工作区应该围绕上下文组织 Markdown 很适合承载这类信息，并不是因为 AI 对某种格式有偏好，而是因为它结构清楚、成本低、容易检索和版本管理，也能同时被人和机器阅读。真正重要的不是文件后缀，而是信息是否被明确分类、建立入口并持续维护。 一个最小工作区可以这样组织： AGENTS.md background/ conventions/ artifacts...

关联文档：[[AI skill 如何产品化]] AI 落地不一定要开发一个新软件 很多人提到 AI 落地，首先想到的是开发一套新系统：做网页、做账号、做菜单，再培训员工如何使用。但在真实工作中，新系统往往意味着新的学习成本。员工本来就在钉钉沟通，如果只是为了使用 AI，还要打开另一个应用，使用率很容易下降。 我在尝试场地安全巡检时，发现还有一种更直接的方式：把 AI 接到大家已经在使用的钉钉群里。现场人员不需要学习新的工具，只要像平时汇报问题一样，拍照、补充一句说明，然后 @群里的巡检机器人即可。 机器人收到文字和图片后，把照片交给 AI，并同时提供企业已有的巡检要求、标准案例和物料说明。AI 根据这些材料检查照片，再把结果发回原群。整个过程看起来就像群里多了一位随时在线的巡检助手。 一次巡检是怎样完成的 假设现场人员发现某个施工区域可能存在安全隐患。他打开钉钉群，拍摄现场照片，并发送： @巡检机器人，请检查这个区域是否符合安全要求。 后面的事情由系统自动完成。机器人取得原始照片，AI 对照巡检标准查看画面中是否存在防护栏缺失、通道堵塞、物料堆放不规范、人员防护用品不完整等问题，然后组织成一条容易阅读的回复： 巡检结论：疑似不合格 发现问题：临边区域未发现完整防护栏 风险等级：高 判断依据：巡检规范 3.2 处理建议：暂停附近作业，并补充防护设施 请安全负责人结合现场情况复核。 现场人员不用整理表格，也不用把照片转发给不同部门。问题、照片、初步判断和后续讨论都留在同一个群里，其他相关人员可以立即看到并继续处理。 需要注意的是，机器人并不会偷偷读取群里的所有聊天。只有成员主动 @机器人时，这条消息才会进入分析流程。这既是产品能力的限制，也让使用者明确知道：哪一张照片正在被送去分析。 真正重要的不是 AI 看图 视觉模型能识别图片，但“看见”不等于“会巡检”。如果只问 AI“这张照片有没有问题”，它只能依据通用常识回答，结果很难符合具体企业的管理要求。 这类场景真正有价值的部分，是把企业原本分散在文档、表格和老师傅经验里的标准整理出来。例如，什么情况属于高风险，什么距离算合格，发现问题后应该采取什么措施，哪些情况必须由人工到场确认。AI 有了这些依据，才能从普通的图片识别工具变成一个懂业务规则的助手。 因此，一套可用的 AI 巡检方...

AI 使用能力十级分级 这套分级主要用于评价一个人使用 AI 解决实际问题的能力。这里的 AI Agent 包括 Codex 等通用 Agent，也包括企业自行研发的 AI Agent 平台。 分级不能只看一个人使用了什么工具。真正需要评价的是：他能独立解决多复杂的问题，能否稳定复现结果，是否具备工程化能力，以及最终能创造多大的业务价值。 严格来说，只有第 1～8 级属于“使用 AI”的能力范围。模型微调和模型开发是在生产、改造 AI，而不是使用 AI。之所以仍将它们列为第 9、10 级，并不是认为它们是更高级的 AI 使用技巧，而是为了尊重创造和改进模型的人，为整套分级保留一个通向模型创造者的位置。 十级能力模型 等级 能力定位 可观察的能力标准 1 AI 直接对话使用者 能使用豆包、ChatGPT、Codex 等在线 Web AI 的直接对话模式，完成问答、总结、翻译、资料整理等单次任务。此阶段只评价对话使用能力，不包含 Codex 工作区操作。 2 高质量提示词使用者 能在直接对话中写出质量较好的提示词，清楚说明目标、背景、约束、输出格式和示例，并通过多轮反馈持续改善结果。 3 Agent 工作区协作者 能使用 Codex 等 Agent 的工作区模式，向 Agent 提供文件、代码和项目上下文；能让 Agent 修改真实项目，并主动检查变更、测试结果和潜在错误。 4 Agent 任务编排者 能把复杂目标拆解为多个可执行步骤，合理安排上下文、工具、检查点和人工确认；能使用搜索、代码执行、浏览器、MCP、Skill 等能力完成跨步骤任务。 5 AI 自动化开发者 能使用模型 API、脚本、工作流平台和结构化输出，把 Agent 接入现有业务系统，实现批处理、定时任务、数据处理和跨系统自动化。 6 AI Agent 应用开发者 能针对具体业务研发 Agent 应用，完成工具调用、RAG、记忆、状态管理、权限控制、异常处理、评测、部署和持续迭代。 7 AI Agent 平台架构师 能建设可复用的 Agent 平台，支持多 Agent 编排、模型路由、工具治理、权限与安全审计、可观测性、成本控制、评测体系和规模化交付。 8 企业级 AI 赋能专家 能系统识别企业主要...

关联文档：[[../../_archived/软件随笔/旧时随笔/前Blog/Mac打开隐藏文件]] 两个快捷键，解决两类高频操作 我在和别人一起处理文件时，经常看到一种低效但很常见的操作：Finder 窗口越开越多，桌面上层层叠叠；需要找配置文件时，又因为目录里“什么都没有”而转去终端输入命令。其实，这两类问题分别对应两个很简单的快捷键： Command + T ：在当前 Finder 窗口中新建标签页。 Command + Shift + . ：显示或隐藏以 . 开头的文件和文件夹。 它们不是什么复杂功能，却能明显改善日常文件管理。尤其进入 AI 编程场景后，配置目录和项目文件之间的切换越来越频繁，这两个快捷键也就比过去更实用了。 用 Finder 标签页集中处理文件 在 Finder 处于当前应用时，按下 Command + T ，会像浏览器一样打开一个新标签页。每个标签页都可以停留在不同位置，例如一个打开“下载”，一个打开项目目录，另一个打开移动硬盘。这样既保留了多个工作位置，又不必让多个窗口互相遮挡。 标签页最直接的用途是搬运文件。macOS 没有完全照搬 Windows 的“剪切文件”交互，除了先按 Command + C 、再用 Command + Option + V 移动文件，也可以直接把文件拖到另一个标签页上。拖动时在目标标签上松手，即可放进具体目录。这种方式适合整理下载内容、归档素材，或者在项目与备份目录之间移动文件。 它也适合比较不同目录。例如，我可以同时打开两个版本的项目、两个命名相近的素材目录，或本地目录与外接磁盘，来回切换检查文件数量、名称和层级。需要把多个位置的内容汇总到同一目录时，标签页也比反复点击“后退”和“前进”更不容易迷失位置。 当标签页较多时，可以通过 Control + Tab 切换到下一个标签页，使用 Command + W 关闭当前标签页。 临时查看隐藏文件和目录 macOS 会默认隐藏名称以 . 开头的文件或目录，例如 .git 、 .config 和 .ssh 。这是为了避免普通用户误改系统或应用配置，但对开发者而言，这些内容经常正是需要查看的对象。 在 Finder 中按下 Command + Shift + . ，隐藏项目会立即出现，通常以较浅的颜色显示。再次按下同一组...

关联文档：[[../../harness/工作台/软件设计/004 Codex 会话模块设计]] 问题背景 我在比较 OpenCode、Codex、Claude、Pi 这些 Agent 工具时，最先需要澄清的是：这里要选的不是一个“最好用的 AI 编程工具”，而是一个适合承载自定义 AI Agent 平台的基座。 这两个问题完全不同。个人使用工具时，重点是交互顺不顺、模型强不强、命令能不能跑通。做平台时，重点变成了运行时边界是否清晰、会话能否管理、事件能否订阅、权限能否控制、文件和 diff 能否被上层产品稳定消费。 所以，我不会把 Claude SDK、OpenAI SDK、Pi SDK、Codex app server 和 OpenCode SDK 简单放在同一个层面比较。它们解决的问题不同，适合的位置也不同。 模型 SDK 和 Agent 运行时不是一回事 Claude SDK 和 OpenAI SDK 更接近模型 API 层。它们擅长解决模型调用、streaming、tool use、结构化输出等问题。如果只是做一个业务聊天助手，或者在后端服务里调用模型完成某个固定任务，它们非常合适。 但自定义 AI Agent 平台需要的不只是“向模型发消息”。平台还要管理项目、会话、消息、工具、文件、命令、权限、事件、diff、revert、模型供应商和审计记录。模型 SDK 不会直接提供这些能力，团队必须自己实现一套 Agent runtime。 这部分工作很重，而且大多不是业务差异化。真正有价值的是平台产品层，比如任务模型、团队协作、权限策略、流程编排、质量审查和交付闭环，而不是重新造一遍文件搜索、命令执行和会话事件协议。 因此，我更倾向于把 Claude SDK、OpenAI SDK 放在 provider 层，而不是把它们作为整个平台的基座。 Pi 更像极简可改造的 harness Pi 的定位很清楚：它是一个极简 agent harness，强调“让 harness 适应你的工作流”。它支持 extensions、skills、prompt templates、themes，也提供 interactive、print / JSON、RPC 和 SDK 等多种使用方式。 这个设计对个人工作流很有吸引力。Pi 的核心很轻，扩展空间很大，适合...

个人能用的 Skill，为什么不能直接卖 我自己使用 Skill 时，允许它有一点偏差。指令不够严密、输出偶尔跑偏，重新运行一两次通常也能得到可用结果。因为我熟悉这套工作流，知道哪里需要补充上下文，也知道什么结果算“差不多”。 但把同一个 Skill 交给别人，情况就完全不同了。购买者不会替产品猜测隐藏规则，也不会接受“再跑几次就好了”。他关心的是：输入是否清楚、输出是否稳定、失败能不能解释、结果能不能验收。用户付费买的不是一段漂亮的 Prompt，而是一条可重复获得结果的路径。 所以，从 Skill 到可售卖产品，关键并不是继续堆指令，而是把 Skill 中可确定的部分迁移到代码脚本里。让模型负责理解和生成，让程序负责约束、校验和交付。 先找稳定输出，再决定怎么写代码 产品化的第一步不是重写 Skill，而是把它当成流程说明，检查它究竟承诺了什么。可以先把流程画成： 输入 → 处理 → 模型生成 → 校验 → 输出 然后为每一步写清楚三件事：输入是什么，输出是什么，哪些条件必须始终成立。比如输入文件必须存在、结果必须包含必填字段、失败时必须返回明确原因。这些条件就是最适合脚本化的稳定输出。 我通常会让 AI 先做一次流程审计：把指令拆成原子步骤，标注每一步依赖规则、数据转换、外部调用，还是人的判断，再列出偏差和可观测的验收信号。AI 适合做枚举和归类，但边界仍要由人确认；看似稳定的规则，可能只是作者习惯，并不适合成为产品承诺。 哪些部分应该转成脚本 凡是“同样输入应该得到同样处理”的部分，都优先交给代码： 读取和规范化输入，例如检查文件格式、补齐默认配置、清理空值。 创建目录、命名文件、写入产物，并限制可访问的路径范围。 把模型输出解析成结构化数据，并检查必填字段、类型、数量和枚举值。 调用外部服务、设置超时、重试可恢复错误，并记录不含敏感信息的状态。 对结果做确定性的转换，例如排序、合并、格式化、导出和生成清单。 在进入下一阶段前执行校验，发现不满足条件时阻止继续，而不是把错误传给下游。 脚本化的价值不只是“更快”，而是把 Prompt 里的约定变成可测试、可记录、可复用的显式接口。用户不必知道用了哪个模型，只要输入输出契约不随模型波动而改变。 哪些部分不应该假装自动化 需要人工经验判断的部分，不必强行脚本化。例如目标...

文件夹解决位置，文件名解决查找 整理文件时，文件夹只能解决“放在哪里”的问题，不能完全解决“怎么找到”的问题。一个文件即使被放进了正确目录，如果名字仍然是 新建文档 、 最终版 、 截图 1 、 资料 ，下次打开时还是要重新猜它是什么。 文件命名的目标不是把所有信息都写进去，而是让自己在不打开文件的情况下，大致知道它的时间、用途和区别。一个好的文件名应该服务三个动作：排序、识别、区分。 文件类型不需要放进命名规则里，因为系统已经通过后缀名说明了类型。比如 .docx 、 .pdf 、 .jpg 、 .mp4 已经告诉你它是什么格式。文件名真正应该表达的，是这个文件为什么存在。 使用三段式命名 一个简单可执行的规则是： 排序依据-功能--补充 例如： 20260719-meeting--finance 这个名字表示 2026 年 7 月 19 日的一份会议文件，主题和财务有关。 20260719 是排序依据， meeting 是功能， finance 是补充说明。 三段式命名的好处是足够简单。你不需要每次重新设计文件名，只要按同一个结构填空即可。第一段回答“它应该怎么排序”，第二段回答“它是干什么的”，第三段回答“它和同类文件有什么区别”。 第一段：排序依据 最常见的排序依据是日期，推荐使用 YYYYMMDD 格式，例如 20260719 。这样按名称排序时，文件会自然按照时间排列，不会出现 7月 排在 12月 后面这类问题。 如果文件不是按时间管理，也可以使用其他排序依据，比如项目编号、课程编号、版本号。但不管用什么，都要尽量稳定。排序依据越稳定，文件列表越容易被扫描。 对于日常个人文件，日期通常已经足够。会议、账单、照片、导出资料、阶段性文档，都可以用日期作为第一段。以后查找时，你即使记不清文件名，也往往能记得大概时间范围。 第二段：功能 第二段写文件的功能，也就是它是什么。比如 meeting 、 invoice 、 resume 、 contract 、 draft 、 note 。这部分要短，不要写成完整句子。 功能字段的作用，是让你快速判断文件用途。比如同一天可能有很多文件，只有日期还不够；加上功能之后，你就能知道哪个是会议记录，哪个是发票，哪个是草稿。 如果你更习惯中文，也可以使用中文功能词，例如 会...

从一个真实场景说起 我以前几乎没有认真想过“怎么整理电脑桌面”这个问题。对我来说，文件放到该放的位置、临时文件用完就处理掉，好像是一件自然而然的事。 直到有一天，我女朋友让我帮她整理电脑桌面。打开之后我才发现，她的桌面乱得跟垃圾桶一样：文件、文件夹、截图、压缩包、文档和各种不知道从哪里来的材料混在一起。她不是不想整理，而是不知道每个东西该放到哪里，也不确定哪些东西能删。 这件事让我意识到，文件夹整理不是一个天然能力。很多人缺的不是耐心，而是一套简单、明确、不会把自己绕晕的判断规则。 先建立少量一级目录 整理桌面或下载目录时，不要一开始就追求精细分类。分类越细，第一次整理越痛苦，后续维护也越容易放弃。更好的做法是先建立少量一级目录，让大多数文件都有地方可去。 可以先右键选择排序方式，推荐“按名称排序”。名称排序比较稳定，也方便后续配合文件命名规则。排序之后，再创建几个一级文件夹。例如： 公司 视频 图片 文档 其他 归档 这里的“公司”“视频”“图片”“文档”只是举例，不是标准答案。你应该根据自己的实际使用场景自行分类。比如学生可能需要“课程”“论文”“证书”，设计师可能需要“素材”“客户”“作品集”，普通家庭电脑可能需要“照片”“票据”“安装包”。 真正重要的是后两个目录：“其他”和“归档”。因为现实中的文件不会都那么规整。只设计明确分类是不够的，还必须给模糊文件和不确定文件留下去处。 “其他”解决分类不完整的问题 “其他”不是垃圾桶，也不是懒得整理时的临时堆放区。它的作用是承接“当前分类体系没有覆盖，但文件仍然有使用价值”的内容。 比如一个文件不属于你已经创建的几个分类，但你能判断它以后可能还会用，只是暂时没有必要为了它单独建立一个一级目录，这时就可以放进“其他”。 “其他”的核心价值，是避免目录结构被低频文件拖得过细。如果每出现一种新文件就创建一个新文件夹，桌面很快会从混乱文件变成混乱文件夹。分类越多，每次放文件时越需要犹豫，整理成本反而更高。 所以，“其他”是一个克制机制。它先接住低频、零散、边界不明确但仍有价值的文件。等某一类文件反复出现，你再从“其他”里把它们捞出来，单独建立新分类。 “其他”也需要定期回看。回看时只判断两件事：有没有某类文件已经多到值得单独分类；有没有文件已经不再需要，可以转入“归档”或删除。这...

关联文档：[[../../../_archived/ai-native/ai-native-new/003 上下文工程]]、[[../../../_archived/ai-native/ai-native-new/007 AI Native 工作台]]、[[../../../_archived/ai-native/ai-native-new/008 企业 AI 原生能力底座蓝图]] 通用 Agent 很强，但它不认识我的公司 我自己是通用 Agent 的重度用户：Codex、Claude Code、WorkBuddy 都在日常用，写代码、处理文档、跑复杂任务，它们几乎是当下最好的个人 AI 助手。 但用得越深，我越清楚它们在公司场景下的边界：拿不到企业内部数据，不理解指标口径和业务流程，进不了审批体系，也不知道公司里谁能看什么、不能看什么。而且员工个人用得越深入，企业的数据外流和使用失控风险反而越大。 这就是我推动公司做自己 AI Agent 平台的起点。这个平台不是再做一个单点 AI 工具，而是打造公司级 AI 原生能力底座：以统一入口，把 AI 能力、内部数据、数据分析系统、业务协同系统、员工经验、知识资产和业务流程连接起来，逐步形成面向全公司的智能协作体系。 目标很明确：让 AI 不只是个人提效工具，而是成为公司创新、知识沉淀、协同办公和安全治理的新基础设施。下面分享我思考这件事的八个方向。 一、集体创新平台 我希望平台能把员工的想法、业务经验、问题反馈和 AI 生成能力结合起来，形成更低门槛的创新入口：围绕经营、门店、项目、产品、流程、客户服务等场景，任何人都可以提出问题、生成方案、验证想法。 用通用 Agent 时我观察到一个现象：优秀的提示词、分析方法和业务模板，都留在员工的个人账号里，人一走就带走了。而在自己的平台上，这些好用法可以从个人使用中沉淀出来，逐步变成团队和公司的通用能力。 说白了，就是 把个人灵感转化为团队资产，把零散尝试转化为组织创新能力 。 二、知识沉淀体系 公司内部的知识分散在制度文档、业务系统、历史报表、项目资料、聊天记录、审批记录和员工经验里，传统方式下难检索、难复用、难持续更新——这是我见过的最普遍的老问题。 平台可以逐步连接内部知识库、数据分析系统和业务协同系统，让 AI 帮员工查找、理解、总结和复用公...

关联文档：[[为什么要做自己的 AI Agent 平台？]]、[[../../../_archived/ai-native/ai-native-new/003 上下文工程]]、[[../../../_archived/ai-native/ai-native-new/008 企业 AI 原生能力底座蓝图]] 先给结论：默认不要自建 如果你是个人开发者、内容创作者，或者只有几个人的小团队，我的建议很直接：不要急着开发自己的 AI Agent，也不要因为担心落后就购买一套新的 Agent 平台。 Codex、Claude Code、WorkBuddy 等通用 Agent 已经很强。再配合 Skills，把固定规则、提示词、脚本和工具调用封装起来，基本可以覆盖写代码、查资料、改文档、分析数据、操作浏览器和执行自动化任务等日常需求。 对个人和小团队来说，真正稀缺的通常不是平台，而是清晰的业务规则、稳定的工作流程和可复用的 Skills。平台只能承载能力，不能替你创造能力。先把现成 Agent 用好，通常比开发或购买一套功能重叠的平台更有价值。 自建最容易低估的是长期成本 做一个能调用模型、显示对话和执行工具的 Demo 并不难，难的是长期维护。 一套可用的平台还要处理模型接入、上下文管理、权限控制、失败重试、日志审计、密钥管理和安全升级。小团队本想用 AI 提效，最后却可能把时间花在维护 AI 工具上。 订阅成熟产品看起来要持续付费，但它同时包含产品体验、基础设施、兼容性更新和故障处理。把开发、运维和机会成本全部算进去，自建往往并不便宜。同样，已经使用成熟 Agent 后，再购买功能相近的平台，多数时候只是增加一个入口和一份费用。 开源也不是免费答案 不从零开发，拿开源 Agent 平台改造，确实可以降低起步成本，但不代表后续成本低。 很多开源平台为了覆盖更多用户，包含多租户、应用市场、复杂编排和庞大后台等功能。团队要先读懂架构，再判断哪些能删、哪些存在隐式依赖。删除无用功能，有时比从最小架构开始更费力。 本地改造还可能与上游升级冲突，复杂依赖带来供应链风险，原有权限模型也未必适合企业。选择开源项目前，还要评估代码规模、模块边界、升级策略和团队能否长期接管。 什么时候应该认真考虑自建 默认不自建，不代表永远不自建。当问题从个人效率升级为组织能力，判...