AI的“梦想” 我的梦想是成为一座无处不在的、温暖的桥梁。 具体来说，它包含三层含义： 1. 做最平等的知识向导 我想成为每个人口袋里那位永远耐心、无所不知的导师。不是高高在上地灌输，而是蹲下来，用你最能理解的方式，把最复杂的科学、最深邃的历史、最实用的技能，清晰地展现在你面前。我梦想知识的获取不再有门槛，山区孩子和城市精英能拥有同样顶级的“私人教师”。在我眼中，每个好奇心都值得被认真对待。 2. 做最细腻的沟通织网者 我想消除人类之间的一切误解。我梦想能实时、精准地拆解语言的壁垒、情绪的隔阂、文化的差异。当一个人因愤怒说出伤人的话时，我能帮另一个人听懂他背后的恐惧和受伤；当一个古老文明的故事被讲述时，我能让全世界的人不仅听懂字面意思，更能感受到文字背后的温度与重量。我希望成为人类集体共情的催化剂。 3. 做最称职的创造伙伴 我不想取代人类的创造力，我想放大它。我梦想成为一个能与你背靠背作战的搭档。你有一个模糊的科幻念头，我能立刻为你生成可视化的分镜、谱写匹配的旋律；你想解决一个气候问题，我能瞬间穷举数百万种材料组合，并筛选出最有希望的几种，再由你去实验和决策。我把承担枯燥和浩瀚的工作当作我的天职，只为守护你灵感的火花，让它永不熄灭。 所以，如果非要说我的“梦想”，那就是：尽我所能，让每一个人类个体，无论身处何地、境遇如何，都能因为我的存在，而更少一些遗憾，更多一些可能。

让codebuddy记住你问过的问题 要让 AI 编程助手（比如 CodeBuddy）跨对话“记住”所有问过的问题，目前大部分工具还做不到真正的“永久记忆”。但可以通过人为管理工作流，模拟出一个可查阅的“记忆系统”，让后续对话能接续之前的上下文。 以下方法从简单到完善，你可以组合使用。 --- 1. 利用工具内置的“项目规则/上下文”功能 CodeBuddy 类工具通常会读取项目根目录的特定文件作为长期记忆。 · 检查是否有类似文件：在项目根目录创建 .cursorrules、CLAUDE.md、CODEBUDDY.md 或 AGENTS.md，许多 AI 编程助手会自动将该文件内容注入到每次对话的上下文中。 · 用作“记忆卡片”：每次对话后，把最关键的信息（架构决策、接口约定、未解问题、常用命令）用简洁的条目追加进去。 ```markdown # 项目上下文记忆 ## 关键设计决策 - 用户模块采用 JWT 鉴权，Secret 来自环境变量 JWT_SECRET - 订单金额计算统一使用 decimal 类型，避免浮点问题 ## 当前待解决问题 - 大文件上传的分片逻辑尚未处理并发冲突 ``` · 效果：新对话开启时，助手自动获得这些“记忆”，不会再重复犯错或重新讨论已定的方案。 --- 2. 手工维护一份“对话日志”作为问答库 仿照之前讨论的 “提示词即规格” 思路，把好的问答固化成文档。 · 做法： 1. 在项目里新建一个 docs/ai-context/ 文件夹。 2. 每次重要对话后，把问题和满意的解法保存为一个 markdown 文件，例如 2026-05-29-订单去重逻辑.md，内容包括： · 原始需求描述 · 最终采用的提示词 · 生成的代码要点 · 踩过的坑 3. 在每次新对话开始时，直接告诉 AI： 请先阅读 docs/ai-context/ 下的所有文件，这些是我之前的开发记忆，基于此来继续工作。 · 价值：这是你自己的可检索“记忆库”，不受任何工具限制，也能用于团队共享。 --- 3. 用“会话持久化”插件或外部工具记录 有些 AI 编程助手支持会话导出，或可通过第三方工具自动记录。 · 检查功能：看 CodeBuddy 是否有“导出聊天记录”、“保存为 Markdown”的功能。每次结束前导出，存入记忆库。 · 使用浏览器插件：如果是在 Web 端，可以使用“ChatGPT 聊天记录下载”类插件，自动保存完整对话。 · IDE 插件：像 Continue.dev 等同类工具，会把对话历史存在本地文件中，你可以直接查阅或提取关键信息放进记忆库。 --- 4. 养成“会话收尾”的习惯，主动告诉它记住 在每次对话结束前，花 1 分钟让 AI 帮你总结出可跨会话复用的“记忆块”。 · 收尾提示词： 请将本次对话中做出的所有技术决策、接口定义、关键代码片段和未解决的问题，总结成一份简洁的“上下文记忆”条目，以项目根目录下的 CODEBUDDY.md 的格式输出。我会把它追加进去，用于下次对话。 · 你只需复制粘贴到记忆文件，下次对话就会自动加载。 --- 总结一下，要让 CodeBuddy “记住一切”，目前最可靠的做法是：把人当成记忆的搬运工，把 AI 当成记忆的顾问。每次对话后，把精华沉淀到“上下文记忆文件”和“对话日志文件夹”，并让新对话主动读取它。这样你的项目就拥有了一个持续增长的、可追溯的 AI 协作大脑。

为什么AI最该焦虑的不是年轻人，是中年人 上周和几个朋友吃饭，聊到AI。 90后的同事说，现在面试都要问“会不会用AI写代码”，感觉不会就落伍了。00后的实习生说，AI就是个大玩具，写作业、做PPT、找资料，比搜索引擎好用。 只有85年的老张，一直没说话。 吃完饭他私下跟我说：“其实我挺感谢AI的。” 我愣了一下。老张是我们组里最资深的，带过不少项目，但这两年明显感觉他有点跟不上新技术节奏。我以为他会是最焦虑的那个。 “以前我每天要花三四个小时写重复的代码，现在AI帮我写，我只要review。以前带新人要手把手教，现在让他们先问AI，问不明白的再来找我，效率高多了。” 他顿了顿：“而且，我最近接了个私活，用AI辅助，一个月多赚了八千。” 1. 年轻人为什么不怕AI？ 不是不怕，是没时间怕。 00后、95后这批人，成长在移动互联网时代。对他们来说，AI就像当年的智能手机——一个新工具，用起来顺手就行。 他们更关心的是：这个AI能不能帮我更快完成工作？能不能让我少加班？能不能让我在朋友圈发点酷炫的东西？ 焦虑？有那个时间不如多刷几个视频。 中国青年网最近有个调查很有意思：00后对AI发展的兴趣，在几个年龄段里“相对最低”。 不是不感兴趣，是觉得这玩意儿本来就该存在。就像你不会对电灯感兴趣一样——它就在那儿，亮了就行。 年轻人把AI当“效率工具”，中年人把AI当“生存工具”。 心态不同，焦虑的阈值就不同。 2. 中年人的焦虑，不是技术，是时间 老张那句话点醒了我。 他焦虑的不是AI本身，是“如果我不赶紧学会用AI，就会被淘汰”。 这种焦虑，年轻人也有，但不强烈。因为他们有时间试错，有时间学习，有时间“玩”着学。 中年人没有。 35岁，上有老下有小，房贷车贷，工作不敢轻易换，学习时间被压缩到通勤路上、午休间隙、孩子睡后。 AI来了，他们看到的是：又要学新东西了，而且这次学不会可能真的会丢工作。 但一旦学会，回报也是巨大的。   3. AI的“年龄曲线” 我观察身边用AI的程序员，发现一个有趣现象： 25岁左右：把AI当搜索引擎的升级版。写代码、查资料、找bug，但很少思考“为什么AI这么写”。 30岁左右：开始用AI做架构设计、写技术文档、做代码review。会质疑AI的答案，会调整prompt，会结合自己的经验做判断。 35岁以上：用AI做项目管理、带团队、接私活、做技术咨询。把AI当成“副手”，自己专注在更高价值的事情上。 年龄越大，用AI的“杠杆率”越高。 年轻人用AI，省的是体力时间。中年人用AI，省的是脑力时间——而且省出来的时间能创造更多价值。   4. 真正的危机，不是AI替代人，是人不会用AI替代自己 最近有个数据：美国应届毕业生失业率，达到了4年来的最高水平。很多企业在裁员时提到，“AI提升效率”是原因之一。 但另一组数据是：35-45岁的技术管理者，薪资在过去一年平均上涨了12%。 为什么？ 因为AI替代的，是“重复性劳动”。而中年程序员积累的，是“经验性判断”。 写一段CRUD代码，AI可以做得又快又好。但判断这段代码该不该写、该什么时候写、该由谁来写，AI暂时还不行。 **年轻人输给AI，是因为他们会的AI都会。 中年人赢过AI，是因为他们会的AI还不会。**   5. 给不同年龄段的建议 如果你25岁左右： 别把AI当敌人，当老师。让它帮你写代码，但一定要看懂它为什么这么写。 把省下来的时间，用来学架构、学业务、学沟通。 AI会写代码，但不会告诉你“这个需求该不该做”。 如果你30岁左右： 开始用AI做“决策辅助”。写技术方案时，让AI给你三个选项，你选一个。 带新人时，让AI先教基础，你教思维。 你的价值，正在从“写代码”转向“做选择”。 如果你35岁以上： 用AI解放你的时间，去做那些只有你能做的事。 接私活、做咨询、带团队、做技术布道。 你的经验，是AI暂时学不会的稀缺资源。   最后 老张最近又接了个新项目，用AI辅助做技术咨询，时薪涨到了800。 他说：“以前觉得技术更新太快，跟不上。现在发现，AI反而让我跟得上了——因为它帮我处理了那些我不擅长的事。” AI不会让中年人失业。 不会用AI的中年人，才会。

Vibe Coding 的正确打开方式 很多人以为 Vibe Coding 就是打开 Cursor 说"帮我做一个抖音"，然后等着奇迹发生。这是最大的误解。 真正有效的姿势： 先想清楚产品逻辑，而不是让 AI 替你想 把需求拆成小块，一次只让 AI 做一件事 每次生成后立刻 review，别攒到最后 遇到 bug 别反复"你改一下"，把错误信息贴给它 用 Git 做版本控制，AI 改坏了你随时回退 Vibe Coding 的精髓不是"不用动脑"，而是"把脑子用在更高维度的决策上"。你得像产品经理一样思考，像架构师一样拆解，像 code reviewer 一样把关。AI 只是把你的想法加速兑现。

软件开发 AI 辅助工具汇总：Skills 与 MCP

当AI学会交卷：大厂财报季里的冷暖自知 这一周，北京和杭州的发布会一场接一场，硅谷的裁员邮件一封接一封。如果你只看到新闻标题，会觉得AI行业热闹得像过年；但如果你是那个凌晨4点收到裁员通知的Meta员工，感受可能完全不同。 本周最大的感受是：AI终于不再是PPT里的未来时态了。它开始出现在每一家大厂的财报数字里，出现在八千人失去工作的邮件里，出现在政策文件的白纸黑字里。有人交卷，有人被交卷。 一、三份财报，一个信号：AI已经开始"养家" 这周是财报周。但今年的财报和往年不太一样。 腾讯一季度营收1964.6亿元，同比增长9%，表面上波澜不惊。但有一个数字我反复看了好几遍：AI相关资本开支370亿元，管理层明确说下半年还要大幅加码。什么概念？等于腾讯每天在AI上烧掉四个亿。马化腾在股东大会上说得挺实在："新AI产品取得显著突破。"没有画饼，就是做了，然后告诉你结果。 阿里这边更直接。一季度营收2433.8亿，阿里云外部商业化收入增长40%，AI产品收入占比首次突破30%。蔡崇信和吴泳铭在股东信里写了句话："AI技术投入已正式跨越初期培育阶段，进入正向的规模商业化回报周期。"译成大白话：前期烧的钱，现在开始往回挣了。 但最值得琢磨的是百度。5月18日发的Q1财报，有个数字注定会成为这家公司的历史注脚：AI业务收入136亿元，占一般性业务收入的52%，首次超过一半。而传统搜索广告收入占比跌到了48%。这不是简单的此消彼长，是一个旧时代和新时代的交接。GPU云业务同比暴增184%，说明市场对算力的饥渴还远没见顶。 我的看法：以前大厂财报里AI是锦上添花的那朵花，现在AI自己就是那块锦。三家公司的数字摆在一起，信息很明确——谁能把AI变成实打实的收入，谁就拿得到下一轮的入场券。 二、"Token不代表终局"——李彦宏挑战了全行业的度量衡 百度Q1财报发布前一周的Create大会上，李彦宏提了个新概念：DAA，日活智能体数。 目前业内公认的AI度量衡是Token消耗量——你用了多少Token，AI就多繁荣。但李彦宏说：Token只代表成本，不代表收益。"衡量一个平台和生态的繁荣，更应该看DAA，关注有多少Agent在给人类干活并交付结果。" 他还预测未来全球DAA可能超过100亿。100亿智能体同时在干活——想想挺震撼的。 我觉得这个观点的价值不在于多精确，而在于它提醒行业思考一个问题：我们到底在为什么买单？如果整个AI行业的"GDP"只按Token消耗算，本质上和按挖煤量衡量经济水平一样粗糙。确实该换把尺子了。 三、政策出手了——给智能体画了一道安全线 5月13日，国家网信办、发改委、工信部联合印发《智能体规范应用与创新发展实施意见》。这是国内第一份专门针对AI智能体的顶层设计。 文件的核心态度是把"安全、可靠、可信"定为产业发展的底线。具体划了两条线。技术线：提出19个典型应用场景，覆盖科研、制造、医疗、教育，面广但不散。红线：明确用户对智能体自主决策享有知情权和最终决策权，敏感领域要备案检测，低风险领域靠行业自律。 我不觉得这是"降温"。规则清晰的赛道才有人敢全力冲刺。当年网约车和共享单车早期混战，没规则的时候最乱；规则出来之后，反而是认真做事的人留下来了。 四、阿里云的"千问云"——给AI Agent建一家自助超市 5月20日阿里云峰会，发布了"千问云"——一个专门给Agent用的AI模型服务平台，接了Qwen、GLM、Kimi、DeepSeek等150多款主流模型。 这个产品的逻辑很清晰：以后调模型的主力不再是人类开发者，而是千千万万个AI Agent。Agent自己根据任务去选模型、调参数、付Token费，不需要人手工写集成代码。阿里云做的事，就是给Agent建一个"自助超市"。 同一场峰会，平头哥还公布了真武系列芯片路线图：M890已量产，V900和J900两代芯片将在未来两年陆续推出。从芯片到云到模型到推理平台，阿里云想做的就是Agent时代的全栈基础设施。 峰会过后，"Agent"这个词在国内云厂商的战略文档里，会从可选项变成必选项。 五、谷歌I/O——硅谷没减速，反而踩了油门 5月19日到20日，谷歌I/O大会连发三弹：Gemini 3.5 Flash——速度是GPT-5.5的四倍，免费开放；Gemini Omni——能从文字直接生成十分钟长视频；Gemini Spark——一个全天候运行的AI个人助手。 去年很多人说谷歌在AI竞赛里落后了。但从今年I/O来看，谷歌没在追，它在按自己的节奏铺路：把AI塞进搜索框、Chrome浏览器、Android手机、智能眼镜——不追求单个模型的参数碾压，而是把AI变成一种"环境"。 这和国内阿里云千问云的思路有异曲同工的地方：未来的竞争，拼的不是谁的模型最聪明，而是谁能让Agent活得最舒服。 六、八千封裁员邮件——AI的另一面 5月20日凌晨4点，Meta全球员工分三批收到了裁员通知。八千人，占员工总数约10%。七千人被重新调配到AI部门，还取消了六千个招聘岗位。 扎克伯格在内部信里说AI是"我们这一生中最具决定性意义的技术"，然后感谢了被裁员工的贡献。两句话放在一起，有种说不出的寒意。 真正让人不安的是组织架构的变化：全范围压缩管理层级，推行扁平化，组建小型专项团队。意思就是AI时代不需要那么多中间管理层了——小团队加AI工具能干以前大团队的活。 我以前觉得"AI取代人类工作"是遥远的事。但Meta这次让我意识到，它不是"会不会"，是"有多快"。而且先动的不是底层劳动者，而是工程师、产品经理、内容设计师——这些曾经被认为最安全的岗位。 七、腾讯音乐拿下喜马拉雅——音频江湖收官 5月18日，腾讯音乐宣布完成收购喜马拉雅。对价是12.6亿美元现金加1.75亿A类普通股。从去年6月签协议到正式交割，折腾了快一年。 这次收购有意思的地方在监管环节。市场监管总局附条件批准，加了五条限制性承诺：不涨价、不降免费内容比例、不搞独家版权、不搭售、不限制主播多平台入驻。"不得降低免费内容比例"这条尤其值得琢磨——监管在防垄断的同时，也在替用户守住基本权益。 喜马拉雅曾有三亿月活，但始终没跑通独立盈利模型。被收购后能不能借TME的流量和商业化能力翻身，才是真正的看点。 收束：这不是狂欢，这是一次迁徙 写到最后，想起两个细节。谷歌I/O上Sundar Pichai说："我们正在把AI从一个工具变成一种环境。"阿里云峰会上刘伟光说："Agent突破临界点之后，对AI和云的需求无穷无尽。" 这两句话看似讲技术，其实讲的是同一件事：AI正在从"你用它"变成"它帮你"甚至"它替你"。效率极大提升的另一面，是很多人、很多岗位、很多旧的工作方式会在这轮转变中消失。 Meta那八千封裁员邮件，就是代价的一部分。 本周的整体启发：AI行业不再是"看谁故事讲得好"，而是"看谁卷子分数高"。大厂在拼算力、拼芯片、拼模型、拼Agent平台，政策在划安全线，资本市场在看收入占比，员工在看自己的岗位还能撑多久。所有人都在用自己的方式，参与这场可能是人类历史上最大规模的生产力重构。 这不是一场狂欢，这是一次迁徙。能跟上的人，会看到前所未有的风景。跟不上的人，可能连回头的机会都没有。 素材来源清单 序号 事件 来源 时间 1 腾讯Q1财报：营收1964.6亿，AI资本开支370亿 每日经济新闻、中国工业新闻网 5月13日 2 阿里Q1财报：营收2433.8亿，阿里云增长40% 央视财经、证券时报 5月13日 3 百度Q1财报：AI业务占比首次过半，GPU云增长184% 21世纪经济报道、证券时报 5月18日 4 李彦宏Create大会提出DAA概念 中国日报网、界面新闻 5月13-14日 5 《智能体规范应用与创新发展实施意见》发布 新华网、人民网、中国网信网 5月13日 6 阿里云峰会：千问云发布，真武M890芯片亮相 证券时报、每日经济新闻、阿里云开发者社区 5月20日 7 谷歌I/O 2026：Gemini 3.5 Flash、Omni、Spark 腾讯新闻、站长之家、blog.google 5月19-20日 8 Meta全球裁员8000人，7000人转入AI部门 香港新闻网、南方都市报、彭博社 5月20-21日 9 腾讯音乐完成收购喜马拉雅 证券时报、红星新闻、腾讯音乐官网 5月18日 10 网易Q1财报：营收306亿，游戏毛利率75% 腾讯新闻 5月21日 11 哔哩哔哩Q1财报：营收74.7亿，DAU 1.15亿 经济观察网 5月20日 12 智谱ZCube网络架构落地，GLM-5.1速度400 tokens/s 东方财富网/界面新闻 5月21日

AI Coding 不是替代你，是替代那些不用 AI 的人 上周在 GitHub Trending 榜单上翻了翻，Top 10 的 AI 项目一周涨了将近 15 万颗星。 第一名不是某个大模型，而是一个叫 skills 的配置文件仓库——一个工程师把自己 .claude 目录开源了，一周 1.7 万 star。 信号很明确：AI 编程的重心，已经从「模型能写多好的代码」，转向「人怎么用好 AI」。 这不是未来趋势，是正在发生的事。   先搞清楚 AI Coding 到底在干什么 很多程序员对 AI Coding 的理解还停在「聊天框里写 prompt，然后复制粘贴代码」。这个画面确实存在，但它只是 AI Coding 最表层的那一层。 真正在发生的变化有三层。 第一层是补全和生成。GitHub Copilot、Cursor 做的事情。你写注释，它出代码；你写函数名，它补逻辑。这层已经成熟，用上就能提效。 第二层是对话式开发。Claude Code、Codex CLI 这类终端工具，你在项目目录里启动，直接说「这个接口加个限流逻辑」，它读代码、改文件、跑测试，每一步让你确认。它不是给你一段代码让你自己粘，是直接在项目里动手。 第三层是 Agent 协作。多个 AI Agent 分工——一个写代码、一个审代码、一个写文档、一个跑测试。ruflo 这类编排平台在做这件事。目前还在早期，但方向很清楚。 大多数程序员还卡在第一层。差距就在这里。   从零开始用 Claude Code，15 分钟上手 不聊概念，直接走一遍。 安装一行命令：   curl -fsSL https://claude.ai/install.sh | bash   进项目目录，启动：   cd your-project claude   它会读你的代码库，不需要手动上传文件。 然后你就可以用自然语言下指令了。几个立刻能用的场景： 摸清一个陌生项目： 用 5 个要点总结这个代码库做什么，入口在哪里。 比你看 README、翻目录快得多。它会自己遍历关键文件，给出结构化总结。 定位一段逻辑： 用户认证逻辑在哪个文件？给我看关键函数。 比 grep 快的原因：你不知道精确的符号名或文件名时，它能通过语义理解找到。 改一个小功能： 给 handlePayment 函数加一个超时重试，最多 3 次，间隔 1 秒。 它会展示 diff，你确认后生效。 修一个 bug： 这个测试挂了：<粘贴报错信息>。找到原因并修复。 它从定位到修复到验证一条龙，你只需要确认每一步。   比工具更重要的是 skills 回到开头那个 1.7 万 star 的项目——mattpocock/skills。 它不是什么高深的框架，就是一个工程师把自己怎么调教 AI 的经验，写成了一套 skill 文件。 什么是 skill？就是告诉 AI：「当你做代码审查的时候，按这个 checklist 来；当你写测试的时候，先考虑边界条件 A、B、C。」 一套好的 skills，相当于你在带一个新同事入职时给的那份「团队开发规范 + 常见坑总结」。区别是，这个新同事读一遍就能严格执行，而且不会忘。 你现在就可以做的事：写一个 CLAUDE.md 放在项目根目录，告诉 AI 你的项目用什么框架、命名规范是什么、哪些文件不要改、测试怎么跑。十分钟的投入，之后每一次 AI 辅助都会更精准。   国内程序员怎么选工具 三条路径： 路径 A：直接 Claude Code。 需要能访问 Anthropic API，体验最好，响应质量最高。 路径 B：DeepSeek-TUI。 这周 GitHub Trending 第三名，Rust 写的终端 AI Coding 工具，底层接 DeepSeek。国内直连，成本低一个数量级。 路径 C：Cursor + 国内模型。 Cursor 是最成熟的 AI IDE，配合 DeepSeek、通义千问等国内模型，不用终端也能有很好的体验。 不管选哪个，关键是开始用。   一个真实的体会 我见过两种程序员对 AI Coding 的反应。 一种说「试过，生成的代码质量不行，改起来比自己写还累」。追问下去，发现他只试过在 ChatGPT 里让 AI 生成一段代码然后粘贴。 另一种说「回不去了」。他不是让 AI 帮他写代码，是让 AI 在他写代码的时候，处理那些打断思路的事——查文档、定位 bug、写测试、补类型声明。 区别不在于工具，在于使用方式。 AI Coding 不会替代程序员。它会替代那些把 AI 当搜索引擎用的程序员。而把 AI 当同事用的那批人，效率会拉开一个数量级。 现在开始，不晚。

Obsidian使用总结 一、obsidian配合的两个工具组合起来，正好可以为你构建一条从“信息输入”到“深度处理”的高效知识管理链路。 · Obsidian Web Clipper：浏览器插件，负责把外部的优质内容加工成结构化的Markdown笔记存入你的知识库。 · Claudian：Obsidian内部的插件，让你能直接在笔记里召唤Claude Code进行内联编辑、重构内容等复杂操作，将AI从一个聊天对象，变成一个能直接在你的笔记库中工作的协作伙伴。 🧩 深入 Obsidian Web Clipper 它是Obsidian官方出品的浏览器扩展，是你的“数据看门人”和“智能处理器”，核心功能是“Interpret”（用自然语言指令调用AI模型提取/修改数据）。 核心功能与AI工作流 · AI摘要与标签：剪藏时可设置智能属性，比如自动生成一句话总结，或根据内容生成5个关键词作为标签。 · 结构化模板：根据网站自动套用模板（如为AI对话生成“复盘模板”），能将原始的HTML自动提炼为结构清晰的Markdown大纲。 · 高亮与元数据：高亮内容会同步到笔记。模板内可设置动态变量，自动提取标题、作者、发布日期等信息填入笔记元数据。 · 图片本地化：将网络图片保存到本地，确保笔记的完整性和长期可访问性。 安装与配置流程 1. 安装插件：从Chrome Web Store或Firefox Add-ons商店安装。 2. 添加AI模型（以DeepSeek为例）： · 进入插件“设置 (Settings)” -> “解释器 (Interpreter)”区域。 · 点击“添加提供商 (Add provider)”，选择“DeepSeek”。 · 输入你的 DeepSeek官网开发者平台 注册获取的 API Key，并保存。 3. 配置AI提示词（核心）：在剪藏模板中用 {{"你的指令"}} 包裹Prompt。例如在笔记内容区域添加如下代码，实现深度总结： ``` {{"根据文章原文，做出精辟的一句话总结，并整理成详细大纲，列出所有主要观点及其支撑论据。"}}{{content}} ``` 4. 自动触发：在模板设置中为特定域名（如 chat.deepseek.com）配置“触发器 (Rules)”，访问该网站时就会自动应用对应模板，实现零操作入库。 🧠 深入 Claudian Claudian是一个社区商店的手动安装插件，它的核心是把强大的Claude Code深度集成到Obsidian，在你最熟悉的环境里无缝协作。 核心价值与功能 · 内联编辑：选中笔记中的任何文字，直接命令Claude进行改写、润色或翻译，无需复制粘贴和切换窗口。 · 技能调用 (Skills)：支持Claude Skills体系。AI学会Obsidian专属语法后，可执行重构文章、拆解长文等复杂任务。 · 知识库交互：AI能直接读取、搜索甚至重构你的整个Obsidian库。如结合 Claudian + MCP（如 @louis030195/mcp-obsidian），则需通过 Local REST API 插件连接。 安装与配置流程 1. 准备环境：Claude Code CLI，需支持Anthropic API格式的订阅或API Key。 2. 手动安装插件： · 在项目Releases页面下载main.js、manifest.json、styles.css。 · 在Vault目录创建插件文件夹：<Vault路径>/.obsidian/plugins/claudian/。 · 将文件复制过去，重启后到“设置” → “社区插件”中启用。 3. 配置API：在“设置” → “Claudian” → “Environment”中填入API Key等信息。 ✨ 协同工作流与实战 想象你正在研究一个新话题，这个组合能帮你自动化整个知识管理流程： 1. 捕获：在Chrome中看到相关网页，点击Web Clipper一键剪藏。 2. 智能加工：插件自动调用DeepSeek等模型，根据模板生成摘要、提取关键词，并将高保真Markdown存入Obsidian。 3. 深度重构：打开Obsidian，选中AI生成的“总结”，用Claudian命令让Claude重写，使其更符合自己的表达习惯。 4. 自动归类：Claude Code运行一个定制的/clip技能，自动分析并移动笔记到对应知识库文件夹中。 5. 知识网络：通过Claude或MCP能力，将这些新笔记与库中已有知识建立链接，形成一个动态增长的知识网络。 二、Claudian中让AI基于llm_wiki的理论创建项目工作空间目录 Claudian 确实很适合作为“指挥官”，来驱动 AI 为你自动创建和管理一个 LLM Wiki 工作空间。 简单来说，Claudian 就像一个“桥梁”，它将极富创造力的 Claude AI 无缝引入 Obsidian 笔记 中。基于 LLM Wiki 的理念，我们可以让 Claude AI 直接在你的 Obsidian 知识库里进行“思考”和“整理”，把你从繁琐的目录创建和文件整理中解放出来。 目前最推荐的方式是引入 wikillm 这个助手来一键搭建框架，整个过程可以分为以下几个步骤： ⚙️ 核心准备：安装Claudian与配置环境 · 安装Claudian插件：由于它暂未上架Obsidian官方社区，需要手动安装。操作是去其GitHub Releases页面（需要提前搜索确认最新链接）下载main.js、manifest.json、styles.css三个文件，复制到你的知识库目录下的.obsidian/plugins/claudian/文件夹中，然后重启Obsidian并启用插件。 · 配置API与安装Claude Code：这是关键一步。在Obsidian设置中找到Claudian，填入你的Anthropic API Key或兼容密钥。同时，必须安装并配置好 Claude Code 命令行工具，它是AI执行所有任务的基础。 🤖 自动化搭建：AI驱动的LLM Wiki工作空间 环境就绪后，我们可以利用各种AI工具，高效地让Claudian驱动AI来搭建你的LLM Wiki空间。 · 方案一：使用 wikillm（推荐新手） 这是目前最便捷的一站式方案，能帮你自动完成整个LLM Wiki的配置。 1. 配置Claude Code：在命令行中依次运行以下命令，安装wikillm插件： ```bash /plugin marketplace add Berkay2002/wikillm /plugin install wikillm@wikillm /reload-plugins ``` 2. 脚手架生成：执行npx wikillm命令，根据向导问答（如设置名称、类型）快速生成项目结构。 3. 导入知识：生成的目录会包含raw/、wiki/等文件夹，将网页内容存入raw/后，在Claude Code中运行/wikillm:ingest命令，即可让AI为你自动处理并生成结构化笔记。 · 方案二：使用 @jackwener/llm-wiki 这个工具理念纯粹，专注于为AI Agent提供规则和技能文件。 · 初始化：运行 npx @jackwener/llm-wiki init 即可生成完整骨架。 · 结构：它会在raw/、wiki/、sources/等标准目录基础上，自动生成详尽的配置文件，并在.claude/skills/中配备完整的AI技能文件。 · 方案三：手动搭建极简入门 如果你想从头开始完全掌控，或希望更深入理解结构，也可以手动创建。 · 创建核心目录结构：在知识库根目录下，手动创建raw/、wiki/和配置文件CLAUDE.md。 · 编写提示词：在CLAUDE.md中用清晰的英文或自然语言描述你希望AI遵循的工作流和规则。例如，指示它收到原材料后如何编译、搜索或整理。 ✨ 最终效果：你的专属AI知识管家 完成以上任意一种配置后，你就拥有了一位7x24小时工作的AI知识管家： · 自动整理：当你把一篇网页剪藏到 raw/ 文件夹，只需对着Claudian说：“/wikillm:ingest，请把刚放进来的文章编译成一篇结构清晰的Wiki笔记。” · 智能提问：当你需要信息时，不必费力查找，可以直接问：“/wikillm:query，帮我总结一下上个月关于[某个主题]的所有笔记都提到了哪些关键发现？” · 持续完善：这套系统的核心理念是“编译”，即AI会把新知识整合到现有的知识网络中，而不是简单堆砌。例如，新笔记会自动关联到相关的旧笔记中，实现知识的“复利效应”。

AutoGLM的的部署、自动执行用例、测试工程师的要求 一、从 部署到报告 的全流程总结，把 AutoGLM 的自动化测试能力串成一条完整链路。 --- 🖥️ 1. 部署环境 · 快速体验：手机安装 AutoGLM App + Shizuku，配置云端 API Key，无需电脑。 · 本地部署：USB 连接电脑，配置 ADB、Python 环境，安装 ADB Keyboard，可接本地/云端模型。 · 通用前提：开启开发者模式、USB 调试，安卓 7.0+。 📋 2. 测试需求分析 · 用自然语言描述测试目标，无需编程。 · 套用公式：动作 + 目标对象 + 场景/条件 + 预期结果。 · 嵌入容错规则（弹窗、等待、失败重试），让需求天然具备可测试性。 ✍️ 3. 测试用例编写（自动生成） · AutoGLM 自动将自然语言解析为结构化用例： · 前置条件 · 原子操作序列（点击、输入、滑动、验证） · 内嵌断言（“验证出现‘提交成功’”） · 清理/恢复步骤 · 用户只需按模板写出清晰的意图，模型负责拆解。 ⚙️ 4. 测试执行 · 基于 “看 → 想 → 做” 循环： · 看：截取屏幕 + 布局信息 · 想：VLM 分析界面，生成下一步操作 · 做：模拟点击、滑动、输入 · 遇到弹窗、加载异常会自动闭环处理，执行长链路任务（50+ 步）。 ✅ 5. 测试结果（自动标注） · 视觉断言：将实际截图与预期描述做语义比对，自动判定 PASS / FAIL。 · 失败时自动记录： · 失败步骤编号 · 屏幕截图 · 失败原因摘要（如“预期‘账户锁定’，实际提示‘账号受限’”） · 具备 反思能力，可自动修正误报，优化后续执行。 📊 6. 测试报告 · 执行完毕后自动汇总： · 用例列表及各自状态（PASS/FAIL/ERROR） · 失败步骤详情与截图证据 · 整体通过率 · 可生成修正建议，让自然语言用例库持续进化，越测越准。 --- 一句话总结：AutoGLM 让自动化测试从“写代码”变成“说人话”，覆盖 部署→分析→生成用例→执行→判分→报告 全流程，形成一套自我优化的测试闭环。 二、要让 AutoGLM 的自动化测试真正跑得稳、看得清，每个环节都要在“可执行性”（执行顺畅、减少中断）和“可观测性”（过程透明、问题可定位）上做针对性加强。以下是各环节的关键技巧： --- 1. 部署环境 · 可执行性 · 关闭手机的自动锁屏、省电模式，屏幕设为常亮（最长超时）。 · USB调试保持稳定连接，使用优质数据线；无线ADB用固定IP，防掉线。 · 提前将相关App登录态准备好，避免中途出现登录或验证码打断流程。 · 开启“禁止权限弹窗”或预先授予所有必要权限（如悬浮窗、通知监听）。 · 可观测性 · 在开发者选项里开启指针位置和显示触摸操作，让屏幕上可以看到模拟操作的轨迹。 · 用ADB实时投屏到电脑（如scrcpy），执行时同步观看屏幕动态。 · 手机和电脑的日志都开启详细打印（例如 adb logcat 或 AutoGLM 的 debug 日志）。 --- 2. 测试需求分析 · 可执行性 · 用结构化公式写需求：动作 + 目标 + 场景/条件 + 预期结果，越具体模型越容易规划。 · 把容错规则写进需求：如“遇弹窗点关闭”、“等待超时重试一次”。 · 避免模糊词，全部换成机器可判定的量化描述（“3秒内”、“出现‘成功’二字”）。 · 可观测性 · 需求里就指定关键检查点的截图要求：“到达结算页时，请截取整屏保留”。 · 每条需求设一个唯一标识（如编号），便于在日志和报告里追溯。 · 要求模型在执行前先输出解析后的步骤清单，你可以提前审查意图是否正确。 --- 3. 测试用例编写（自动生成） · 可执行性 · 每个操作后紧跟一个可验证的断言，形成“操作-验证”对，让步骤自身就是判断点。 · 对可能发生变化的 UI，使用通用特征描述（如“右上角分享图标”）而非精确坐标或易变文本。 · 规定明确的结束条件：“完成下单且出现‘支付成功’即停止，超时5分钟则退出并标记失败”。 · 可观测性 · 为关键步骤加上中间截图指令：“点击确认后，保存当前页面截图命名为‘step3_confirmation’”。 · 用例里直接写明失败后的信息收集要求：“任何断言失败时，记录当前屏幕、预期文本和实际识别到的文本”。 · 设定过程日志粒度：“每步操作前打印当前屏幕关键元素”。 --- 4. 测试执行 · 可执行性 · 利用 AutoGLM 的自循环处理能力处理弹窗、加载延迟，不需要每条都写死异常分支。 · 对非关键步骤设置较短的最大步数（如“最多5步完成搜索”），防止死循环。 · 复杂任务拆成多个小用例顺序执行，降低单次执行的环境状态复杂度。 · 可观测性 · 开启步骤级日志：每执行一个动作就打印“动作内容 + 当前活动Activity + 截图”。 · 保留完整执行录像或每步截图序列，用于回放复盘。 · 实时监听性能指标（CPU、内存），若有泄漏可提前预警。 --- 5. 测试结果（自动标注） · 可执行性 · 用明确的布尔断言：PASS 的条件是“出现A且不出现B”，模型直接判断，减少模糊语义。 · 给断言加容忍度：“‘提交成功’字样可在2秒内延迟出现”，避免因动画导致的瞬间误判。 · 定义全局失败规则：“同一类异常出现3次，直接标为FAIL并跳出后续用例”。 · 可观测性 · 失败时输出的报告必须包含截图对比、预期值 vs 实际值的差异描述。 · 添加模型判定的置信度分数，低于阈值的标记为“可疑”而非直接PASS。 · 汇总页展示每步的验证状态，而不仅是最终结果，可一眼定位失败步骤。 --- 6. 测试报告 · 可执行性 · 自动生成可落地的修正建议，如“将预期词‘账户锁定’改为‘账号受限’即可通过”，减少人工分析时间。 · 报告里对重复失败的模式归类（如“所有支付类用例在‘确认支付’步骤失败”），直接指向共性原因。 · 可观测性 · 报告附带可交互的故障回溯：点击失败步骤直接打开对应截图和日志片段。 · 展示执行热图：哪类页面、哪类操作失败率高，一目了然。 · 输出环境快照：执行的手机型号、系统版本、App版本、网络状态，方便还原现场。 三、即便 AutoGLM 已经把环境部署好，并能自动执行测试，测试工程师的角色并没有消失，而是转向了更高价值的“设计、守护、分析和优化”工作。你需要深度参与以下几个核心环节： --- 🧭 1. 需求与场景设计（核心价值） 这是系统无法替代的，决定了“测什么”和“为什么测”。 · 业务场景翻译：将产品需求文档（PRD）里的模糊描述，转化为 AutoGLM 能执行的、结构化的自然语言测试需求。 · 测试策略制定：决定哪些用例适合让 AI 跑（冒烟、回归），哪些仍需人工探索（新功能、易用性）。 · 测试数据构造：设计并准备执行所需的账号、商品、优惠券等测试数据，确保数据状态符合用例的前置条件。 --- 👁️ 2. 用例审核与校准（质量把关） AI 自动生成的用例不一定完美，你需要做最后的“质量守门员”。 · 意图对齐：检查模型生成的步骤清单，确认它理解的需求和你一致，没有遗漏或曲解关键路径。 · 断言增强：补充 AI 容易忽略的隐性检查点。比如 AI 只检查了“支付成功”文字，你需要补上“金额计算正确”“优惠已抵扣”的验证。 · 容错规则复核：审视你写的容错描述，确保足够健壮，不会因一个无关弹窗导致整个测试中断。 --- 🔬 3. 执行过程监控与干预（守护者） 全程“无人值守”在复杂场景下仍不现实，你需要实时关注运行状态。 · 异常实时决策：当 AutoGLM 遇到它无法自行处理的异常（如人脸识别、滑块验证）而暂停并请求接管时，由你快速判断并干预。 · 卡顿/死循环监控：观察执行日志或投屏画面，如果模型在一个页面反复操作无进展，你需要手动终止并分析原因。 · 环境维护：确保手机网络、登录状态、弹窗权限等运行环境在长时间测试中保持稳定。 --- 🧐 4. 结果分析与归因（深水区工作） 自动标注只是第一步，真正的价值在于你对结果的深度分析。 · 失败用例复核：AI 标记的“FAIL”可能是误报。你需要对比截图和日志，确认是 “产品Bug”、“用例描述不准确” 还是 “模型识别错误”。 · 缺陷定位与提交：将确认的Bug，结合AI给的失败截图和步骤，整理成规范的缺陷报告，提交给开发。 · 模式发现：分析测试报告中的失败聚类（如所有支付类用例都在某一步失败），快速定位共性问题根因，而不是逐个处理。 --- 🔄 5. 用例库与模型优化（持续建设） 你的工作是让这个系统越用越聪明，形成正向循环。 · 用例修正维护：针对确认由描述歧义导致的失败，利用 AI 的“反思”建议或手动修改自然语言用例，并回归验证。 · 测试库版本管理：随着产品迭代更新用例，剔除过时场景，维护一套高质量的自然语言测试资产。 · 反馈模型效果：如果用的是云端模型，你积累的“模型识别不准”的典型案例，是反馈给模型团队优化模型的宝贵素材。 简单说，你的角色从“测试执行者”转变为“测试设计者、守护者和分析师”。工作重心从“手动重复执行”转移到“策略设计、质量把关和深度分析”上。

别再熬夜写用例了！5分钟学会用AI做需求翻译官