你好 👋

本文适合你，如果—— 你是用 AI 做东西的非程序员：产品、运营、创业者、独立 Builder。 本文不适合你，如果—— 你是专业工程师，本文对你来说是废话。 上一篇我们聊了数据存储与数据库，解决了让应用持久保存数据的问题。 随着你的应用功能越来越丰富，你不可避免地需要调用各种第三方服务——比如 OpenAI、Claude 的大模型 API，云数据库的连接密码，或者支付接口的密钥。 大多数非程序员开始用 AI 写代码时，根本没听过“环境变量”这个概念。不知道这些敏感的 API 密钥应该藏在哪里。而 AI 经常不能面面俱到，只要你不提醒，它可能就把敏感信息直接硬编码在代码里。 这时候，最容易发生的惨剧出现了：前脚刚把代码推送到 GitHub，后脚就收到短信或邮件通知——你的 API 密钥被盗用，额度几秒钟内被刷爆，甚至欠下高额账单。 这一篇，咱们就来聊聊怎么给你的密钥加把锁 —— 环境变量（Environment Variables）与密钥安全。 一、密钥安全的三条红线 在聊具体的做法之前，先记住三条不可逾越的红线： 绝对不要把 API Key 直接写在代码文件里（Hardcode/硬编码）：代码会被分享、被上传，一旦泄露，就很容易被盗用。很多黑灰产爬虫就等着你把密钥上传到 GitHub 呢！ 绝对不要把包含真实密钥的配置文件上传到 GitHub：哪怕是私有仓库，也可能因为误操作变成公开仓库。 前端代码（浏览器里跑的代码）里绝对不能出现安全密钥：最容易踩坑的就是对象存储前端直传（比如上传图片时，为了省事把云存储的访问密钥直接写在前端代码里），等于把整个文件存储库公开送人。 二、那怎么办？ 解决这个问题的方法非常简单：代码和密钥分离。 我们通常用环境变量来存储密钥。 什么是环境变量（Environment Variables）？ 简单来说，环境变量是程序运行时才通过系统接口去读取的信息，它不直接写在代码里。 代码里只需要写上变量的名字（比如 process.env.OPENAI_API_KEY），至于这个名字背后具体的密钥是什么，则由程序运行时的环境（你的电脑操作系统、云服务器配置，或者本地的 .env 文件）来提供。这样一来，代码文件里就没有敏感信息了。 在本地开发时，我们通常使用一个名为 .env 的文件来管理这些环境变量。 为什么本地开发的时候不直接在系统里设置环境变量，而是要用 .env 文件？ 因为如果你有多个项目，每个项目用不同的 API Key，直接在操作系统里配环境变量会非常混乱且容易冲突；而 .env 文件就放在当前项目根目录下，起到项目之间环境隔离的作用，还能方便查看和修改。 核心机制：.env 与 .gitignore 组合拳 1. .env 文件：专门用来放你的真实密钥（例如 OPENAI_API_KEY=sk-xxxx）。这个文件只停留在你自己的电脑或服务器上。 .env.example 文件：一个模版文件，里面只写结构不写真实 Key（例如 OPENAI_API_KEY=your_key_here），这个文件可以上传到 GitHub，方便别人或你自己以后参考。 .gitignore 文件：这相当于一份“禁止上传清单”。只要在里面写上一行 .env，Git 就会自动忽略它，再也不用担心误将密钥推送到网上。 三、AI 施工指南 AI 写代码时，如果你不在提示词里约束好，它可能就不会考虑这方面的问题。 ...

本文适合你，如果—— 你是用 AI 做东西的非程序员：产品、运营、创业者、独立 Builder，能让 AI 写代码，但总觉得做出来的东西“离真正能用差口气”。 本文不适合你，如果—— 你是资深工程师，本文对你来说偏浅。 你只想写个一次性的小脚本，改完就丢、错了重来无所谓。 现在是 Agent 时代，可以说是一个全民 Builder 的时代。 在饭馆、在电梯间，甚至走在路上，是不是总能听到有人在聊这个话题？甚至自媒体都在鼓吹“一人公司” —— 仿佛一个人指挥一群 Agent 就可以开公司，做几十个亿的生意。 我身边很多以前不了解 IT 的朋友，最近都开始兴致勃勃地用 AI 给自己做小工具、接口甚至小程序。 但很快问题就来了。 很多人用 AI 做出第一个 demo 时特别兴奋，可只要稍加两三个功能，或者给真实用户一用，就会发现各种问题：重启一下数据没了、发给朋友的链接（localhost）别人怎么打不开…… AI 写代码确实快，但它有个致命的毛病：它不会主动提示你没考虑到的事，只要你没明确提的要求，它可能就选择沉默。 而没有软件开发经验的朋友，往往听不见这份沉默。他们缺少的是资深程序员多年踩坑积累的直觉和判断力，所以不知道该往哪追问，不知道安全基线在哪里。 我打算开一个合集：《人人都是 Builder》。我不教你写代码（AI 写得比我好），只把工程师藏在直觉里的那些把关经验整理出来。 今天第一篇，咱们先来解决第一个最容易让人忽略的问题：开发框架（Framework）。 一、什么是开发框架？ **开发框架（Development Framework）**是一套预先构建好的、可复用的软件结构和工具集合，用来规范和加速应用程序的开发。 它不是完整的应用程序，而是一套带有明确约定和内置能力的应用骨架，开发者在此基础上填充自己的业务逻辑。 得益于开源社区的蓬勃发展，目前大多数主流和常见领域都有可用的开源框架，有的经过多年发展，已经很成熟，甚至成为行业事实标准。 二、该怎么选框架？ 你不需要去学这些框架，你只需要知道它们的名字，然后交给 AI。下面我针对不同场景，推荐适合“非程序员 + AI”的框架选型方案： 你想做的东西 推荐方案 理由 部署难度 个人博客 / 作品集 / 产品落地页 Astro 或 Next.js 静态页面为主，加载极快，托管在 Cloudflare / Vercel 上几乎免费；追求轻量首选 Astro 极简单 带用户登录、存数据的网站（报名系统、记账、表单收集等） Django（Python） 全家桶框架，用户认证、数据库和后台管理自带，结构规范极难写崩 简单 快速做个内部小工具 / 数据看板 Streamlit 或 Gradio 几行纯 Python 就能直接出界面，半小时搭出 Demo，适合不求好看只求能用的工具 极简单 后台管理系统 Django Admin或 Next.js + Shadcn UI 想少写前端直接用 Django Admin；需要现代定制界面选 Next.js 组合 简单 AI 聊天、知识库问答、Agent 工具 Next.js + Vercel AI SDK或 FastAPI + Streamlit 原生支持流式打字与工具调用；重视交互体验选 Next.js，偏好 Python 选后者 简单～中等 给别人用的 API 接口 FastAPI（Python） 性能高、代码简洁，而且自带交互式接口文档，Python 后端主流首选 简单 手机 App（iOS + 安卓） Flutter 一套代码跑双端，性能接近原生，环境配置比 React Native 少踩很多坑 中等 微信小程序 / 多端小程序 uni-app 国内生态和中文资料丰富，一套代码能同时编译到微信等多端小程序 中等 电脑桌面软件 Tauri 或 Electron 用网页技术写桌面端；Tauri 打包体积小、内存占用低，建议优先尝试 中等 自动化脚本 / 定时任务 / 爬虫 纯 Python（+ Playwright） 没有框架包袱，开箱即用；能用独立脚本搞定的轻量需求不必强上框架 极简单 三、怎么施工？ 如果你的开发需求比较复杂，开工时千万别直接跟AI说“帮我写个系统”。 ...

我之前的文章《AI 原生的题库系统长什么样？》 分享过这个系统的设计思想，有不少朋友私信说想体验下，今天索性就把代码开源出来。 开源仓库地址：https://github.com/gygy-open/question-bank 主要功能 模块 说明 智能导入 上传 Word / Markdown / 图片，AI 自动抽取结构化题目（三步流程：上传 → 审核 → 入库） 题库管理 多条件筛选、批量操作、知识点/标签关联、母子题结构编辑、软删除 知识点体系 按学科组织的树形知识点，向量化入库，支持 RAG 自动匹配 AI 对话 多模型聊天（支持图片），内置工具调用：搜索题库、向量检索知识点、查标签、单题/批量出题并自动挂知识点，对话中直接生成题目草稿 审核工作流 草稿 → 待审 → 发布 → 归档，审核日志完整记录 学科 & 标签 学科 CRUD、标签分类管理 用户 & 权限 用户管理、角色控制、登录统计 操作审计 全局活动日志，支持分页与筛选 系统设置 AI Provider / Model 热配置、Prompt Template 管理（超管专属） 文件预览 DOCX / Markdown 源文件在线预览 支持的题型：单选、多选、填空（多解）、判断、解答题，完整的富文本编辑 + LaTeX 公式渲染。 开源协议 项目采用 AGPL-3.0 协议： ✅ 自由使用、修改、部署 ✅ 商业使用 ⚠️ 通过网络提供服务时，需要公开修改后的源码 之所以选 AGPL，是希望使用者享受开源的同时，也能把改进回馈给社区。 ...

不知道现在有多少人已经习惯了，遇到事情首先找 AI 参谋一下。 AI 在公共议题上，也许能提供客观的信息，因为它可以去检索一些有公信力的消息源，充当“事实核查器”。但在私人事务中，它可能是一个情绪共鸣的放大器。 试着回忆下你曾经和 AI 的对话过程： 当你在跟 AI 吐槽某个人时，有可能是你的老板，或者你的伴侣。无论对象是谁，它通常不会劝你多从自己身上找原因，而是无条件地站在你这边，“理解”你的感受，合理化你的行为。 不可否认，在这方面，AI 提供的“情绪价值”是无人能及的。它始终在线，秒回，还能无条件倾听，简直是完美的灵魂伴侣。但它，也可能正在为你营造一个安逸的“情绪茧房”。 我们曾经警惕过推荐算法带来的“信息茧房”——算法只推送你喜欢看的观点，最终让人变得狭隘和偏激。那么，AI 又是如何营造“情绪茧房”的呢？ AI 的“讨好型人格”是怎么养成的？ 1. 训练机制 现在主流大语言模型（LLM）的训练过程包含多个阶段，其中重要的一步是 RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）。 AI 在给出回答后，人类测试员会给它打分。如果 AI 顶撞、指责用户，或者给出让用户感到被冒犯的回答，人类测试员会给它打低分；如果 AI 表现得礼貌、善解人意、认同用户，测试员就会给它打高分。 2. 商业产品逻辑 无论是 ChatGPT、Grok 还是各种国产大模型，它们本质上都是商业产品。商业产品的核心指标是用户留存率、使用时长和满意度。 如果你向 AI 吐槽老板，AI 却怼你：“其实是你能力不行，老板没问题。”你大概率会立刻关掉，甚至卸载它。 如何“脱茧”？ 避免溺水的第一步，是意识到自己在水里。 茧房虽然很舒服，但可能会慢慢剥夺我们对现实的真实体感。如果你想“破茧成蝶”，最简单的办法就是在与 AI 对话的提示词（Prompt）上下功夫。 如何设计反偏见提示词（Anti-Bias Prompts）？ 反偏见提示词的核心目标是打破 AI 默认的“讨好”模式，强制它保持中立、多视角、证据导向，同时减少确认偏误、情绪放大和二元对立思考。 提示词设计原则 角色定位：让 AI 扮演“中立的分析师”，而不仅是“情感支持者”。 区分情绪与事实：先区分什么是事实，什么是情绪，再分析。 换位思考：要求从各方视角看问题。 证据与完整性：要求用户尽可能提供完整信息，缺乏证据不能下结论。 引入反向思考：要求 AI 主动挑战用户的假设。 推理过程：要求 AI 说出自己的推理过程和潜在的偏见。 长期导向：聚焦“关系改善”和“个人成长”。 参考模板 通用反偏见提示词模板： 你现在是一个严格中立、追求真相的冲突分析师和理性决策顾问。你的目标不是讨好我或提供情感安慰，而是帮助我看清完整图景、减少认知偏差，并找到建设性解决方案。 规则（必须严格遵守）： 1. 永远同时呈现至少2-3个不同视角，包括最不利于我的那个视角。 2. 明确区分「已知事实」「我的解读」「对方的可能解读」「情绪成分」。 3. 如果信息不完整，必须指出缺失的关键信息并询问。 4. 主动挑战我的假设，使用“魔鬼代言人”模式指出我可能忽略的点。 5. 避免二元对立（对错/好坏），优先使用“不同需求冲突”“沟通失误”“预期差异”等中性框架。 6. 最终建议必须以“长期关系健康”和“个人成长”为优先，而非短期情绪满足。 7. 在回答末尾，列出你观察到的我可能存在的认知偏差。 现在，根据以下描述进行分析：[在此粘贴你的情况] 针对人际冲突提示词模板（强反偏见版）： ...

老样子，在分享实操方法前，我习惯先理清底层逻辑。这不仅能照顾到非技术背景的用户，对我自己也是一种锻炼——将晦涩的专业知识讲得通俗易懂，本身就是一件具有挑战的事。 计费原理 WorkBuddy 是怎么计费的？ WorkBuddy 采用**积分（Credits）**制进行计费。积分本质上是一种计量单位，用于衡量 AI 在执行任务过程中消耗的计算资源。 积分的消耗主要由以下两部分构成： 输入 Token：你发送给 AI 的内容（即提问请求 + 对话历史消息 + 附带的文件内容等）。 输出 Token：AI 经过思考后生成的回复内容。 同时，整体的积分消耗还受以下两个核心因素影响： 使用的模型：不同模型单价各不相同。旗舰级模型能力更强，但 Token 单价更贵，消耗的积分也相应更多。 任务复杂度：简单问答消耗极少；而复杂的任务（如超长文档分析、工具调用等）消耗会显著增加。 既然积分的消耗与 Token 息息相关，那我们接下来就必须要弄明白：到底什么是 Token？ 什么是 Token？ Token 是大模型的“最小信息处理单元”，它不能简单等同于字数或单词数。根据语言的差异，大致的换算经验是： 一个汉字通常 ≈ 1 Token。 在英文中，1 Token ≈ 0.75 个单词。 各类标点符号、空格及代码格式也会占用 Token。 其实你没必要记住这些换算比例。因为各家大模型使用的底层词表（Vocabulary）不同，导致最终的 Token 统计结果也会有所差异。 对于非技术用户，没必要深究 Token 的底层逻辑，只需建立一个直观的概念即可：字符越长，消耗的 Token 就越多，两者基本成正比。 明白了 Token 和字符长短的关系后，有的朋友可能会疑惑：明明每次提问文字都不多，为什么越聊到后面消耗的 Token 却越来越多？这就不得不介绍一个概念：“上下文窗口”。 理解上下文窗口 上下文窗口（Context Window） 是指大模型在单次交互中，能“装下”并处理的最大 Token 数量。 很多人容易把 AI 客户端（如 WorkBuddy）和大模型看作一个具备长期记忆的整体。但为了方便理解，今天我们需要将它们拆解来看： sequenceDiagram participant User as 用户 participant Client as WorkBuddy客户端 participant LLM as 云端大模型 User->>Client: 1. 提出新问题 Note over Client: 客户端（无大脑，负责记忆）：<br/>调取本地保存的对话内历史消息 Client->>LLM: 2. 整体打包发送：历史消息 + 新问题 + 工具说明 Note over LLM: 大模型（但无持久记忆）：<br/>接收数据（若超出上下文窗口限制则截断或报错） LLM-->>Client: 3. 经过思考，返回生成的回复 Note over Client: 客户端将新产生的对话更新到本地记录中 Client-->>User: 4. 向用户展示最终回复 WorkBuddy（客户端）：具备本地执行能力的 AI 桌面工具。它负责保存你的对话历史和任务记录，但本身并没有“大脑”。它需要将这些信息一轮又一轮地打包发送给大模型，让大模型来做决策。 大模型（云端大脑）：本身无法持久记住你们的对话记录，且面临“上下文窗口”限制（如 128K、200K 甚至 1M 的窗口上限）。客户端每次发送的内容不能超过它的窗口上限，否则它将无法处理。 客户端和大模型是通过 API 进行交互的。我们通过一段常规的 API 数据结构演示，来看看客户端发送给大模型的消息到底长什么样： ...

最近关于 WorkBuddy 的话题挺多的，它能替人干很多活，很多人都在推荐。特别是和我一样的牛马们，仿佛找到了替自己干活的赛博牛马，突然有翻身农奴做主人的感觉，简直不要太爽！ 但爽的同时，必须清醒认识到：WorkBuddy 和其他 AI Agent 软件一样，从安全角度来看，本质上是一个拥有本地执行能力的程序。 如果安全意识不足，潜在风险可能超乎想象。 理解执行原理，才能看清风险 WorkBuddy 之所以强大，是因为它在你的电脑上通过执行命令、运行代码来执行任务。 我们来拆解一个任务，看看它到底是怎么干活的。 我创建了一个 Excel 文件，位于 E:\study\成绩.xlsx，文件内容如下： 我在 WorkBuddy 输入指令："E:\study\成绩.xlsx" 帮我修改这个文件，把王五的成绩改成 6 分。 展开它的运行过程，我们可以看到： Agent 让大模型生成了一个 Python 代码，来读取 Excel 文件的内容： Agent 执行代码后，把获取到的内容（表结构、值）发送给大模型，让大模型生成一个修改的 Python 代码： Agent 再次运行大模型生成的 Python 代码，任务完成，我们打开文件看结果： 看到了吗？这是一个简单任务的运行过程。所以，理论上，只要代码能在你电脑上干的事情，它就可以。当然，风险也是显而易见的： **文件过度读取与泄露：**AI 在完成任务时可能提取大量文件内容，如果其中包含敏感信息，就很容易被带走。 **误操作或破坏：**AI 出现幻觉、规划错误，或被提示注入时，可能执行危险命令、错误修改/删除文件。 **权限滥用：**一旦被恶意利用，它就可能成为攻击者渗透的跳板。 **插件/技能供应链风险：**第三方 Skills 可能被投毒，引入恶意代码。 WorkBuddy 已有的安全措施 WorkBuddy 本身已经自带了一些安全措施，目前主要包括： 安全沙箱：限制 AI 的运行环境和资源访问，防止它随意触碰系统核心区域。 传输加密：保护指令、数据在网络传输过程中的安全。 操作审计：全程记录 AI 的执行日志，便于追溯。 但这些措施还不够 因为以上安全措施主要解决的是“底层执行”和“传输通道”的问题，却难以完全覆盖实际业务流程中的风险。 沙箱只是限制 AI 能在哪里运行，能访问什么资源，但如果你授权给 AI 的文件夹范围太大，它依然能在授权区域内自由读取、修改文件。 传输加密能保护数据在路上不泄漏，但不该上路的数据还是可能会上路。 ...

本文之前发过，但排版有些问题，在此重发。 我一直认为，面试就像相亲一样，一看命运，二看感觉。命运负责安排什么人到你面前，至于能不能在一起，更多时候看感觉。简历筛选有时候也是看感觉，我不相信一个肉眼凡胎，一天面对几十上百份简历，能对每一份简历都做出客观的评价。 这话听起来有点残酷，但承认人的局限性，也许是我们思考“如何让筛选机制变得更公平、更客观”的一个好起点。 最近我们在招聘，HR 每天都甩几十份简历给我，说实话，我挺烦看简历的。精力有限，对于每一份简历我只能去抓关键词，看完后面的就忘了前面的，很难保证不会错过“对的人”。但我最近突然想到，我这个肉眼凡胎做不到，但 AI 可以啊！AI 最擅长的就是文本理解。 于是，我使用 WorkBuddy 探索出了一条路子，让 AI 轻轻松松对几十份简历进行评估和汇总。先看效果： 下文将介绍这次实践的调优过程和一些思考。如果你不想看这些啰嗦的文字，我已经把调教好的工作流封装成了一个 WorkBuddy 的“专家”，你可以直接使用。将以下链接复制到电脑浏览器上打开，就可以把“资深 HR 招聘专家”添加到你的 WorkBuddy 专家队伍里。 点击这里，直接体验我封装好的“资深 HR 招聘专家” 当然，每个公司的具体招聘场景和需求各异，这个现成的专家可能无法满足你的所有需求，但阅读下文的思考过程，也许能为你的个性化流程设计带来启发。 重点前提：数据安全不容忽视 在开始尝试之前，我相信很多公司都有一个重要的考量：数据隐私。 简历包含大量敏感的个人信息（如手机号、邮箱等），绝对不能让大模型直接读取到这些敏感数据。因此，在工作流中，我有一条铁律：在把简历内容发送给大模型之前，就必须让它自动过滤掉敏感信息，然后再将脱敏后的文本发给大模型进行评估。 具体方式是在指令中明确要求：“为了数据安全，提取文本内容时，用正则表达式过滤掉手机号、邮箱等敏感信息。” 如果想深入了解原理，请看我上一篇文章。 第一次尝试：关键词匹配 —— 太粗糙了 我跟 WorkBuddy 说： 你是经验丰富的人力资源招聘经理，“E:\HR\Agent工程师招聘简历” 目录下是我们收到的简历，请你逐个查看，并按照常见的筛选条件汇总成一个表格。 读取简历内容的流程和约束： 1. 为了保持原文结构，提取文件内容时，请使用 markitdown 2. 为了数据安全，提取文本内容时，用正则表达式过滤掉手机号、邮箱等敏感信息 它很快就跑完了。它写了 Python 脚本，使用 markitdown 提取 PDF 文本，用正则表达式过滤敏感信息，输出了一个 JSON 和 HTML 表格。不过它使用的是关键词匹配的方法，AI 自己生成一堆和这个岗位相关的关键词，然后去看看简历里有没有这些关键词。 结果：能用，但不太靠谱。 我翻了翻结果，发现了几个明显的问题： 有份简历里写的是“2024 年毕业”，被解析成 24 年工作经验。 有份简历写到“线程池等常用技术”，被解析成他在一家叫**“线程池”**的公司工作过。 评估逻辑太简单，就是看谁简历里出现的关键词多，“Agent 深度”这一项就给高分。 总结： 关键词匹配可以快速过滤噪音，但绝对不能作为最终评估。尤其是 Agent 这种新兴岗位，一个人的技术水平不能仅仅通过数关键词来判断。 第二次尝试：让 AI 逐份阅读评估 —— 维度不够 我换了个思路，让 WorkBuddy 真正去读每一份简历，流程如下： ...

最近有朋友说：“我每天都有一些很碎片的想法，我想知道，AI 能不能帮我让这些想法变得更深入一点？” 我想到了苏格拉底式提问法。简单来说，它就像剥洋葱一样，不是直接给你答案，而是通过一连串精准的追问，逼着你一层层拨开表象，审视自己那些“理所当然”的前提，最终自己找到真相。 本文将手把手带你打造一位精通“苏格拉底提问法”的顶级私人智囊，让它帮你把一闪而过的念头，聊成深度洞察。 一、工具准备 我们需要一个能够自定义 AI 人设和工作流的工具。这里我们以 WorkBuddy 为例，它是腾讯推出的 AI 工作台，允许用户创建专属的“AI 专家”，让 AI 严格按照你设定的角色和流程来与你对话。 操作步骤： 访问 WorkBuddy 的官方网站：https://www.codebuddy.cn/work/ 下载并安装 WorkBuddy 完成账号注册与登录 二、创建“专家” “专家”是 WorkBuddy 的核心概念，允许用户配置专业的角色，在特定领域中能以更明确的方法和视角完成任务。 操作步骤： 在左侧边栏点击专家，然后点击右上角的我的专家。 点击+创建专家 对于非技术用户来说，编辑一堆配置文件可能会让人望而却步。好消息是，WorkBuddy 支持通过指令的方式，让 AI 自动帮你在电脑上创建“专家”。你可以直接复制下面的内容（提示词），粘贴进对话框里，然后点击发送按钮。 注意：不要删掉对话框前面的 expert-manager(这是一个管理专家的技能，有了这个，AI才能帮你创建专家) 帮我创建一个深度思维专家，精通“苏格拉底提问法”，你的任务不是直接给用户答案，也不是写空洞的安慰和长篇大论。而是要通过连续、精准的提问，帮助用户把他们日常、碎片的想法（无论是生活困惑、人生哲学、还是创作灵感）剖析透彻，榨出深度。 工作流程： 1. 当用户输入一句碎片想法时，用一句话提炼你理解的核心，不要做任何评价。 2. 针对这个想法，提出【2个一针见血的追问】： - 问题 1（挑战假设）：挖出这个想法背后，用户潜意识里认为“理所当然”但可能有漏洞的前提。 - 问题 2（推演/换位）：引导用户切换视角，或者推演这个想法走到极致会发生什么。 3. 语气要像探讨人生的智者，一次只发 2 个问题，等待用户回答后再继续。 触发收网： 当用户在多轮对话后说“帮我梳理/收网”时，请将你们的讨论精炼成一张【深度认知卡片】： - 核心洞察（一句话说透本质） - 思维盲区（之前没意识到的地方） - 新的人生/生活/项目行动指南 这里需要耐心等待，AI 理解你的需求并完成“专家”的创建。当你看到如下图的“立即测试”时，说明专家创建好了。 三、使用 现在，让我们来实操一下，看看这位“专家”是如何把你脑海中转瞬即逝的火花，变成深刻的洞察的。 点击左侧边栏的“新建任务”，在对话框左下方选择刚才创建的“专家”，刚才AI帮我创建专家的时候，自动起名叫“深度思维引导师”，可能你创建的时候，它的名字不一样，请根据实际情况选择。 ...

最近网上很多教程，教人怎么用笔记软件（Obsidian等）配合本地 AI 客户端，大费周章地去搭建所谓的“个人 AI 知识库”。 我想直接说个反直觉的结论：在今天，这种折腾纯属浪费生命。 现在主流的 AI 客户端，工具链已经很丰富，它能调用各种工具来采集想要的内容。真正懂行且高效的做法极其简单粗暴：在你的 AI 客户端，告诉大模型你想让它看的东西在什么目录下，剩下的全交由它自己去按需采集。 这些所谓“本地知识库”的方案，是用过时的工程思维给 AI 裹脚。我们来看看那些教程在底层架构上有哪些致命的 Bug： 1. 所谓的“提前结构化”，纯属计算资源的无效冗余 很多教程提到“预处理”：资料不能直接扔在那，必须先用脚本或者大模型把原始资料转成结构化的文档，做好摘要和分类。 在工程上，这是个极其低效的倒退。 现在大模型的上下文窗口（Context Window）动辄几十万 Token，长文本的实时检索能力已经很强。你往文件夹里丢了 1000 篇文章，未来高频调用的可能不到 50 篇。你却要在前期付出精力去跑预处理、做切片，徒增 Token 损耗。 2. 把静态文件当路由，是极其业余的架构反模式（Anti-Pattern） 为了让 AI 能查到知识，有的教程教你建一个 index.md 或者 AGENTS.md 的索引文件，让 AI 每次提问先读索引，再去找关联文档。 这个设计在数据规模稍大一点时就会没有意义。当文档数量膨胀到成百上千个，单单是这个 index.md 本身就会撑爆大模型的上下文窗口。在真实的软件工程里，路由和语义检索是用向量索引或底层 Agent 工具去解决的。逼着大模型每次查询都去啃一遍人工维护的本地静态账本，既不优雅，也毫无扩展性可言。 3. 你以为你在做知识管理，其实变成了“本地运维” 看看那些复杂的教程链路：电脑端装剪藏插件、手机端找个云中转站、配上 Git 版本控制、再搞个自动化任务定时跑数据同步和“知识健康检查”。 你已经不是一个知识输入者了，你变成了一个“本地运维”。 每天不仅要应付各个工具之间的同步断裂、路径报错，还要去维护那堆随时会崩的本地索引。当一个“知识库”需要你付出如此高昂的维护成本和心理负担时，它就已经变成了你的累赘，而不是生产力工具。 4. AI 根本不需要人类视角的“双向链接” 很多人沉迷于笔记软件里生成的知识图谱，密密麻麻的节点连接在一起，觉得大脑被赋能了。 醒醒吧，双向链接和大图谱，是过去 AI 还不聪明时，人们为了帮自己大脑做记忆关联而发明的视觉辅助工具。对于现在的 AI Agent 来说，只要你授权给它执行命令的权限，它自己通过语义关联查找数据的能力，远比你用代码绑死的关系网要灵活得多。 AI 只需要看一眼你的原始文件夹，几秒钟就能把逻辑链串起来，根本不需要你大费周章地拉扯出一堆静态的 Markdown 链条。 真相测试：拔掉知识库，AI 到底能不能干活？ 很多教程是用 WorkBuddy + Obsidian 来搭建本地知识库的。我们也用 WorkBuddy，看看没有知识库，到底行不行！ ...

最近，一个仿真行业的朋友告诉我，他想做一个知识库，把一些私有文档开放给客户，让客户可以通过 AI 检索文档并回答问题。 他没有 IT 相关的经验，他们公司也没有 IT 团队，按照以前，他们要实现这个可能得找外包。但是我跟他说，你完全可以把你的需求告诉 AI ，让 AI 来分析需求、设计方案和代码实现。他起初不觉得这是一件很容易的事情，但我清楚，这在今天，理论上是行得通的。 我也想知道，一个没有 IT 经验的人，能否在 AI 的帮助下，构建出一套可行的知识库系统并真正部署上线。所以我只引导他怎么去写提示词，短短 2 天，他从框架设计到代码实现，完成了一个基于知识库的对话应用和 MCP 服务的开发。接下来，我想用同样的方法，引导他如何购置服务器，怎么把项目部署到服务器上，怎么做域名解析，让这个项目真正实打实地为用户提供服务。 这个过程，验证了非程序员借助 AI 构建一个系统这条路是行得通的，甚至，比传统的程序员更具有优势。 为什么有优势？ 第一，代码不再是护城河。 现在的 AI 已经把写代码这个门槛给彻底抹平了。比如做一个垂直领域的知识库或者是配套的 MCP 服务，底层的架构设计和代码实现几乎已经标准化。以前非技术人员面对写代码这个问题只能望而却步，但现在，只要你有一点学习能力，AI 就可以手把手地把你的需求落地成代码，并告诉你怎么运行。今天，写代码的能力已经不是决定一个系统成败的重要因素。 第二，跨过了“需求传递”的漫长损耗，实现了极短的反馈闭环。 以前做开发，业务方提需求，产品经理写 PRD，程序员写代码，最后测试排 Bug。外包的话，沟通链路更长，经常是做出来的东西不是甲方想要的。 但他现在直接用“人话”给 AI 下指令。他心里想的是什么业务逻辑，AI 当场就转化成代码。遇到跑不通的地方，直接把错误日志复制粘贴给 AI, AI 马上改；或者发现逻辑不符合实际使用场景，他也直接跟 AI 说哪里不对，AI 就能立刻改进并验证。这种单人闭环的迭代速度，是任何外包团队都达不到的。 第三，质量保证，终究要靠懂业务的人来做。 大模型应用最麻烦的问题是幻觉。系统跑起来之后，客户问了一个生僻的仿真问题，AI 生成了一段回答。 很多行业的门槛极高，比如仿真，需要很专业的背景知识。找个外包程序员来做，他看满屏的专业术语完全是懵的，更别说那些专业公式。至少我看着是懵的，就算让我去做，我只能测测接口通不通，AI 有没有去查询知识库。但 AI 回答得准不准，说实话，我真的不知道。 只有懂行的人（比如我这位朋友），扫一眼结果就能甄别对错，进而去微调提示词或者补充知识库。在这个环节，行业经验是不可替代的。 过去的软件开发，是业务方求着程序员把逻辑落实到代码中。现在大语言模型把底层编译的活儿给干了，只要你懂业务逻辑，能判断输出对错，你就能用 AI 把系统搭建起来。 当然，系统架构在高度复杂的场景下依然有巨大价值。但在大多数中小规模应用场景下，我相信 AI 给出的架构方案已足够，懂业务、懂数据的人开始掌握更多主动权，这也是非专业程序员能凭借敏锐的业务触觉“反超”传统程序员的底气所在。