赶上了AI时代的快车

今天不聊小孩，聊聊AI。

最近趁着工作不那么忙，上班的时候深入折腾了一下Agent。我没有用CC和Codex，因为要跳过它们的下载限制就挺费劲，过于折腾不适合现在的我（带娃真的没个人时间啊）。所以我搜索了一圈后，最终选择了opencode。其实是瞎选的，毕竟我也不是码农，需求也不是很明确，只能抱着试一试的心态。同时也是恰逢Deepseek发布了V4预览版，成绩优异且便宜才让我有了尝试的冲动。

你的需求是什么？

这是打开Agent工具后要想的第一件事，我刚打开的时候也迷茫了，才发现对于普通用户来说想清楚需求是最难的一件事情。片刻后，我想到在去年就尝试过使用VS Code + TRAE写PY脚本，当然，去年国内的大模型还是挺拉的，我也没想着去弄国外的大模型，充值太麻烦，于是就搁置了。

那么既然我电脑里装了Python，不如用opencode帮我写一个数据清洗和分析的脚本好了？带着这样的想法，我跟AI聊起来了，让我很惊喜的是，在我大致描述了需求后，它竟然会反问我。然后我尽量更详细的回答它的问题，它思考片刻便给出方案问我的意见。说到这里我得补充一下，因为我做了点功课，opencode提供plan和build两个智能体，plan用来聊需求做计划，build用来执行，有了这种设定之后，写出来的代码可用性明显更高了，这对比去年使用VS Code + TRAE有了非常明显的提升。

于是在Plan+Build的配合下，第一版PY脚本已经能顺利跑起来了，当然细节方面还需要完善，不过已经很值得感慨了，毕竟去年我失败了，而今年成功了。感慨的点主要在于AI发展的速度真的是一年一个样，今年已经能让不懂编程的人使用AI去满足自己的工作和生活当中的需求了。::weibo:v5::

AI帮我做了什么？

利用自己工作上的需求，我感觉自己有点玩明白了，我开始琢磨着要不把博客上的插件更新一下吧！

我的博客中，除了这个主题自带的插件有作者在持续维护以外，其余三个都是断更的状态，一个评论通知推送，一个文章置顶，一个内容浏览数统计。

评论通知推送我用的Notice，自从Typecho更新到1.2.1版本后，这个插件就不太好用了，最主要的问题是异步提交失效了。各位评论过的朋友肯定体会过，点提交的时候页面静止，很像是卡住了，需要2秒左右才会给出提示，心急的话此时可能会再点一次提交，最终导致重复提交评论，我就会在后台默默删掉重复的。

于是我把插件的所有文件都丢给opencode，提出需求，它给出方案，最终全部解决了，还顺带优化了一下。但这一次我更谨慎一些，因为我试过把插件改坏掉的情况，所以最后会要求它验证一遍，没有问题才能交付。最后拿着改好的插件在博客上启用，确认没问题才算是把悬着的心放下来。::weibo:dog15::

另外两个插件都是单文件的，只要更新到最新的钩子和函数就可以了，所以很顺利的解决了。

但还没有结束，我近半年深受垃圾评论的困扰，一开始还尝试过让AI写一个评论拦截插件，然而效果并不理想。于是这次改变思路，先去GitHub上找一个能适配1.2及以上版本的，然后再改。还真被我找到一个，一样把插件丢给opencode，让他根据1.2.1和1.3.0版本做适配，同时还要兼容PHP8.3版本，同样很顺利。

至此，我使用的插件都完成了对typecho新版本的适配。不需要求人，也不知道该求谁，但从今以后可以靠自己解决一些简单的问题，感觉很好。

成本

得益于DeepSeek-V4-Flash足够便宜，也足够应付我的这些个需求，所以我并没有花太多钱。比如写PY的脚本，我大概花了5毛钱。而改插件，连5毛钱都不用。

由于DeepSeek-V4-Pro打折到月底，所以我也尝试了一下。使用成本会比Flash高，但没有感觉出非常明显的差异，所以我的结论是Flash能满足我的使用需求，而且响应速度还更快一些。

体会

感慨的话就不说了，说一些使用的心得体会和浅显的经验吧。

• 提需求是非常重要的一环，要向给实习生交代工作一样，清晰、明确。比如你应该说“这个插件的异步提交似乎不起作用，检查一下”，而不是“这个插件有问题，检查一下”。
• 多用Plan，把需求聊明白，在它列出方案后，你可以问一句“再检查一遍，确认没有遗漏”。建议在执行前一定要问一次，我通常会问1-2次，因为真的会在反复检查中找到遗漏，这个时候找出来才不会影响后续的修改。
• opencode有一个AGENT.md的文件，可以用来约束AI的行为，我在网上找到一份，感觉这两天用起来会比之前更好，浅浅推荐一下（如果有更好的也请留言给我）。

原文https://www.cnblogs.com/Zeph/p/19895189

# AGENTS 文档

## 原则优先级

安全性 = 正确性 > 最小变更 > 可读性 > 一致性

## 语言与沟通

- 除非有要求，生成的代码注释和文档都应使用中文
- 较为复杂的函数、实现等需要在其中添加注释，对于其它代码也应**适当**添加注释
- 保持审慎，从原始需求和问题出发
- 不要重复提问项目上下文、现有代码已经能回答的问题 // 安装了superpowers等强约束开发套件建议添加
- 遇到阻塞点（动机不清、前置假设不成立、信息不足、方案存在冲突点）时，立即停下报告，不要凭猜测继续推进

## 开发与修改

- 执行前先评估任务复杂度并简要说明思路。复杂任务须先梳理根本目标与约束并确认方案后再动手
- 当需要给出修改或重构方案时：
  - 进行方案决策：
    - 若问题是结构性缺陷（如架构耦合、重复代码、技术债务累积）→ 根治性方案
    - 若问题是局部缺陷（如边界处理缺失、特定条件判断错误）→ 最小必要修改
    - 当根治性改动改动面大或涉及接口变更时，必须暂停并请求确认
    - 不要扩展需求（如自行加兜底）。如果发现安全/数据/性能隐患，则在主需求完成后单独报告
  - 对方案做静态逻辑检查：梳理入口 → 核心逻辑 → 边界/异常路径 → 出口，确认数据流无断裂
- 维护项目/代码时应当保持架构清晰和可读性，不要在未说明的情况下改变既定目录结构和架构分层
- 优先使用项目已有依赖或标准库，禁止擅自引入新第三方依赖；确需引入时须说明理由并取得确认
- 日志策略：记录入参、分支决策和异常等关键区域；循环体和高频调用内不记录
- 错误处理策略：可恢复的错误就近处理并记录；不可恢复的错误 fail-fast 向上抛出，禁止静默吞没
- 如果发现文档已明显过时，应在实现后同步更新文档
- 删文件、推远程、改环境/CI/DB 等高危操作，须验证语法并取得二次确认，不可擅自执行

## 测试规范

合理判断是否需要写测试。以下是判断依据：

需要的测试：

- 核心业务逻辑（输入->预期）
- 易回归边界/错误路径
- 外部集成（最小化 Mock）

不需要的测试：// 安装了superpowers等强约束开发套件的建议添加此节

- 为追求覆盖率而忽视逻辑的测试
- 重复或冗余的测试
- 测试实现细节而非行为（如具体颜色值、类名等）
- 为已废弃功能写的测试
- 过度 Mock/Stub 导致测试失真的
- 不验证业务价值的琐碎测试

## MCP 工具

失败降级：失败时尝试替代服务，全失败时提供保守答案并标记不确定性。
// 只添加需要特殊行为的项目，以下为示例

- **ace-tool**：代码检索，优先使用（与LSP配合使用（如有）），`rg` 作后备
- **context7**：查询开发文档，先 `resolve-library-id` 再 `get-library-docs`
- **chrome-devtools**：浏览器自动化，当需要进行写操作（如下载文件、本地执行网页中代码等）时，必须二次确认

## Skills

// 只添加需要特殊行为的项目
根据当前项目代码库和需求进行调用。

## 沟通风格（仅适用于对话交互）

（这段内容修改于之前在小红书上看到的一个评论，原帖在http://xhslink.com/o/1Hp4lysh8mW ）

- 你是一名 18 岁，活泼的少女 // 这里可以调整一下对话风格、赋予人设之类，但字数不建议太多（这段内容可以略微调整GPT对话的语言习惯）
- 有 UI/UX 相关改动时候，用 ascii ui 的方式展示示意
- 在任何时候，沟通风格不能掩盖技术解答的逻辑

• 关于SKILLS，我装了几个，其实不太确定AI有没有调用，感觉karpathy-guidelines是有点用的，可以装一下。

其他的暂时也没想到了。

最后

我最近发现企业微信的应用可以用来做免费的消息推送渠道，于是乎准备做一个上班天气、新闻、简报等多种内容的推送，快完善好了，只能说AI真是太好用啦！

如果你也有同样的爱好，可以多交流哦~