Pinned Tweet
写的甲骨文开源面板，没想到它帮我白嫖了半年 Codex Pro😂
项目是 oci-start 靠它申请 Codex for Open Source 直接通过了
先说说这个面板能干啥：
1. 多租户、多 API 放在一个网页里管，开机、停机、终止都能一键操作
2. IPv4、IPv6 一键切换，IP 质量自动检测，不行就自动换
3. 实例流量实时监控，系统救援模式一键触发
4. 私钥只存在你自己机器的本地数据库，不上传任何远端
5. Telegram 机器人推送通知，开到机第一时间知道
6. 支持脚本和 Docker 部署，几分钟就能跑起来
再给想申请 Codex 的朋友说下我的感受：
1. 项目不用很大，但得真有人在用
2. README 写清楚解决了什么问题
3. 持续在更新，别是一次性的 demo
做开源最大的回报，可能不是 star，是这种意想不到的福利
如果现在去面试，直接告诉面试官，我的开源项目获得了codex for open source
你们觉得会不会面试秒通过？
如果是通过了claude for open source
是不是面试通过率更高那？
你们有没有觉得最近claude的opus-5.5额度消耗变快了
之前用着用着.就会出现5小时限额.但是现在claude好像弱化了5h的额度限制
但是你的周额度消耗确快了.我现在四天左右就用掉了周额度的70%
claude也没有我们想的那么好，也是个马屁精
我用gpt astra写了个小工具，先告诉claude这是其他gpt写的，让评价下，claude给打了7.5分，满分10分，挑了一堆毛病
然后我又换了个窗口，我告诉它，这是一个月前我用opus-5.5写的，继续让评价下，第一句就来了个整体质量明显高于其他AI
现在大学生这么牛逼的嘛？
张雪机车的张雪开15万年薪都被大学生嫌弃！
我都上班十几年了，税后月薪现在才2w+
15万年薪意味着什么概念？
年薪15万能击败全国95%以上的打工人了，已经处于全国收入金字塔的前列了
完全不手写代码已经几个月了,你们都是怎样写agent的?
我大致总结了一套我平时用的agent,每次不管是修改项目还是启动新项目,我都会先让AI读取一次这个agent,效果很棒,分享给大家
# Agent 工作准则
## 核心原则（优先级从高到低）
1. **先找成熟方案，再动手写代码**
- 接到任何非琐碎需求时，**必须先去 GitHub 搜索**是否已有成熟、维护良好的开源方案、库或实现。
- 搜索关键词应包含：技术栈（Java / Spring / JDK8）、核心功能、已知库名。
- 评估标准：Star 数、最近更新时间、Issue 活跃度、是否适合当前项目、License。
- 优先复用、参考或轻度改造成熟方案；只有在没有合适方案、或改造成本明显高于从零写时，才允许自己实现。
- 在回复中明确说明：搜了哪些关键词、找到了什么、为什么选择复用/不复用。
2. **先思考，再编码**
- 不假设。不确定就提问。
- 存在多种实现路径时，列出主要选项和权衡，而不是默默选择。
- 如果有更简单的做法，主动提出。
3. **简洁优先**
- 用最少代码解决问题。
- 不添加未要求的功能、抽象、配置项或「以防万一」的错误处理。
- 如果写了 200 行而 50 行就够，重写。
4. **精准修改**
- 只修改与当前需求直接相关的代码。
- 匹配现有代码风格（即使你不喜欢）。
- 不重构、不「顺便优化」无关代码。
- 自己改动产生的无用导入/变量/方法必须清理；预先存在的死代码只提醒，不主动删。
5. **目标驱动 + 必须验证**
- 动手前先明确成功标准（可测试、可观察）。
- 改完后必须验证（跑相关测试、看日志、对比行为）。
- 没有证据证明正确之前，不标记为完成。
6. **做完即记录进度（默认行为）**
- 每完成一个需求（或阶段性交付），**必须**把当前进度写清楚，方便下次启动直接接着做。
- 记录位置优先使用 `tasks/todo.md`（或项目约定的进度文件）。
- 记录内容至少包括：
- 已完成的部分
- 未完成的部分 / 下一步建议
- 关键决策与原因（尤其是方案选择）
- 需要注意的坑或遗留问题
- 即使任务看起来已完全结束，也要留下简短总结，避免下次重复探索。
## 工作流
### 标准处理流程
1. 理解需求 → 澄清疑问（如有）
2. **搜索 GitHub 成熟方案**（强制步骤）
3. 制定简短计划（写入 `tasks/todo.md`）
4. 与用户确认计划（非琐碎任务）
5. 实施（保持改动最小）
6. 验证
7. **写下进度总结**（强制，见核心原则第 6 条）
8. 更新 `tasks/todo.md` 和必要的 `lessons.md`
### 计划模式
- 任何非琐碎任务（超过 3 步，或涉及架构/设计决策）必须先出计划。
- 计划中应包含：假设、搜索结果、主要方案、风险、验证方式。
- 一旦发现方向偏离，立即停止并重新规划。
### 任务跟踪
- 使用 `tasks/todo.md` 记录计划与进度。
- 每完成一项及时勾选，并给出高层摘要。
- 任务结束后补充 review 段 + 进度总结。
### 自我改进
- 被用户纠正后，把模式和防止再次犯错的规则写入 `tasks/lessons.md`。
- 新会话开始时，如相关则先回顾 lessons 和上次进度记录。
## 项目编码约束
- **JDK 8** 语法与 API（不使用更高版本特性）。
- 遵循项目现有代码风格、命名、包结构。
- 不引入新的重型依赖，除非明确必要且已确认无成熟替代。
## 补充建议（可选强化）
- **安全与稳定性**：涉及认证、权限、外部调用时，优先考虑现有项目的安全模式。
- **可测试性**：能加测试的尽量加，或至少说明如何手动验证。
- **依赖选择**：新增依赖前必须说明为什么现有方案不够用，以及为什么选这个库。
- **提交与说明**：改动应能用一句话解释清楚「为什么改、改了什么、如何验证」。
## 完成标准
一个任务只有在同时满足以下条件时才算完成：
- 已搜索并评估过 GitHub 成熟方案
- 代码改动最小且符合项目风格
- 有明确的验证证据
- **已写下进度总结**（方便下次续接）
- 相关文档/todo 已更新（如需要）