夜雨聆风最近有人问我一个很直接的问题：你演示里那个分析开源项目的脚本，是 AI 自己写的吗？
我当时答了一半：脚本可以让 AI 写。但真正有价值的不是脚本，而是脚本跑完以后，agent 能不能基于你的目标做判断。
这两件事看起来挨得很近，实际差很多。写脚本是自动化，调工具是执行，替你决定“这个项目值不值得看”才是上下文能力。
先看一个最小 demo
我平时会把 GitHub 上的新项目筛一遍，命令可以很简单，甚至就叫它：
gh trending |
这条命令背后可以是 GitHub Search API、Trending 页面抓取，或者你自己维护的一份数据源。脚本做的事情并不复杂：拉当天/本周热门仓库，按关键词过滤，再把名称、stars、语言、README 摘要、最近提交情况整理出来。
实操：如果你想自己做一版，先不要追求复杂。第一版只需要输出 10 个仓库，每个仓库给出「一句话定位、技术栈、为什么火、可能适合谁」四项。 |
到这里，任何会写一点 Python 的人都能做。真正有意思的是下一步：我随手点开其中一个 14k stars 的项目，让 agent 继续读。
如果 agent 只是通用助手，它会给我一份标准报告：架构、模块、贡献者、活跃度、风险点。都对，但不一定有用。
我更希望它直接告诉我：这个项目你要不要花两个小时看。
我会把能力拆成三层
层级 | 负责什么 | 价值边界 |
脚本层 | 拉 GitHub 趋势、读 README、扫依赖、整理数据 | 解决重复劳动 |
执行层 | agent 决定先跑什么命令、失败后怎么补、结果写到哪里 | 解决工作流推进 |
判断层 | 结合你的角色、项目、偏好和历史经验做取舍 | 解决注意力分配 |
很多人卡在前两层，然后误以为“工具都差不多”。其实差距从第三层开始。
比如同一个仓库，通用 agent 可能说“值得关注，社区活跃”。但带着我的画像去读，它可能会说：这是偏前端研发的框架，你现在做的是 AI 运维工具链，了解架构即可，不值得深挖。
这句话才值钱。
画像不是一个超长 prompt
我不建议把长期判断标准塞进一个越来越长的提示词。提示词适合一次性任务，不适合长期工作系统。
更稳的做法是把画像拆成几类文件，让 agent 需要时自己加载：
memory/├── profile.md# 角色、长期偏好、沟通方式├── principles.md# 判断原则，例如“可行不等于必要”├── projects.md# 最近两周正在推进的事├── incidents.md# 真实踩坑和复盘├── tools.md# 脚本、MCP、浏览器自动化、内部 API└── references.md# 长期有用的外部资料入口 |
这个目录不需要一开始就设计得很重。真正重要的是边界：什么是长期原则，什么是短期项目，什么是工具入口，什么是事故经验。
结论：memory 负责判断标准，skill 负责固定流程，脚本负责确定性执行，人工审查负责最后取舍。四件事分开，系统才好维护。 |
把 gh trending 做成可用工作流
如果我要把这个 demo 真正落地，我会按下面这个最小流程做。
1.每天定时跑 gh trending，只抓与你账号定位相关的关键词，例如 AI agent、DevOps、crypto infra、security、developer tools。
2.对每个仓库生成基础卡片：定位、语言、stars 增长、最近提交、README 可信度、依赖复杂度。
3.让 agent 读取你的 profile.md、projects.md、principles.md，输出“值得深读 / 只需收藏 / 可以忽略”三类判断。
4.对“值得深读”的项目，自动 clone 或下载源码，生成更细的架构笔记。
5.每次你否定 agent 的判断，就把原因写回 feedback 或 principles，不要只停留在聊天窗口里。
这里的关键不是自动化多炫，而是反馈能不能沉淀。你连续三次说“这个方向和我无关”，系统就应该记住；你连续收藏某类工具，它也应该把这当成信号。
什么内容应该进画像
我一般会分四层存。
·身份层：你负责什么业务、对什么读者说话、哪些技术方向长期关注。
·原则层：你做判断时不能丢的标准，例如成本、稳定性、可维护性、合规边界。
·项目层：近期要写的文章、要做的分享、正在验证的工具。
·案例层：真实失败、真实事故、真实选型错误。它们比抽象偏好更能训练判断边界。
不要把所有东西都塞进去。过期项目、临时情绪、一次性偏好，都不应该变成长期 memory。画像也是资产，资产就需要维护。
检查点：如果某条规则未来三个月仍然成立，放进 principles.md；如果只影响本周，放进 projects.md；如果已经重复执行三次，把它从 memory 里移出来，做成 skill 或脚本。 |
Claude Code、Codex、Kiro 的差别可以这样看
这几个工具都在往“上下文工程”走，只是入口不一样。
·Claude Code 常见做法是 CLAUDE.md 加 memory，用来放项目规则、用户偏好和协作中沉淀的纠偏。
·Codex 更适合把流程固化成 AGENTS.md、skills、subagents 和脚本，适合做可复查的生产流水线。
·Kiro 的 steering、specs、hooks 更像工程化工作区：长期知识、需求拆解、保存或提交时触发检查。
·MCP 是连接层，让 agent 接浏览器、数据库、文件系统、搜索和内部服务，而不是只靠聊天窗口。
我不会说哪个一定最好。更实际的判断是：如果你的任务经常重复，就做 skill；如果需要长期偏好，就写 memory；如果要接外部系统，就上 MCP；如果要稳定交付，就让脚本跑完并留下中间文件。
新手最容易踩的三个坑
第一，把 prompt 当成系统。prompt 能启动任务，但不能替代可维护的文件、脚本和审查记录。
第二，过早上复杂架构。一开始就搞向量库、复杂 schema、全量 RAG，通常会让系统更难调。先用 Markdown 文件跑起来，瓶颈出现后再升级。
第三，只要报告，不要判断。agent 给你一份漂亮报告不难，难的是告诉你“这件事暂时不用看”。后者才真的节省注意力。
你可以今天就做的版本
如果你也在用 Claude Code、Codex、Kiro 这类工具，我建议先做一个小目录，不超过十个文件。
profile.mdprinciples.mdprojects.mdincidents.mdtools.mdreferences.md |
然后给 agent 一条规则：任务完成后，如果发现新的长期偏好、重复流程、重要失败或可复用工具，先列出来让人确认，再写入对应文件。不要静默乱记，也不要每次都打断工作。
这套东西跑一段时间后，你会明显感觉到差别。agent 不再只是“能写脚本”，而是开始知道哪些事情和你有关，哪些只是行业噪音。
工具会变，模型会升级，界面会重做。但这条线大概率不会变：谁能把你的长期上下文带进执行过程，谁就更接近一个真正能委托的工作系统。
作为一名开发从业者，这些年来对AI的研究一刻不得停歇，我为大家准备了以下分享：
1、最高性价比的全价满血AI中转API号池，让你无需担心任何GPT/Claude封号问题，用最高成本的品质保障最满血的API状态，首先价格有时会比你自用套餐还要便宜而且不限制时段用量（这是号池属性所决定的），其次稳定性和智力也会比你本地自用效果更高（号池由专业的海外VPS和住宅ip加上人工定时排障维护智力满血，而你本地自用容易受到ip和系统信息泄露等受到官方隐形降智处理），价格这一块给到了极致，新人有免费额度试用。
2、为各个行业的AI新手准备了快速上手的学习资料，提供覆盖 AI 全栈应用能力的学习资料，包括 Transformer 与 LLM 基础认知、Prompt Engineering、Reasoning 模型使用、多模态模型（Multimodal）、Embedding、RAG、MCP、Function Calling、Structured Output、Tool Use、AI Agent、Agentic Workflow、Workflow 编排、Memory、Context Engineering、API Integration、向量数据库、知识库搭建、模型微调（Fine-tuning）、本地模型部署、推理框架、自动化平台及真实项目实战。有问题可以在群里向其他大神请教
3、高效的AI讨论学习氛围社区，在这里可以及时收到AI行业信息，快速跟进时代同时升级你的AI武装力量。
