用 Codex 改代码，依据是什么？

前言

最近跟 Codex 聊起了开发规范。项目做了一段时间，想知道之前有没有积累下可用的 Skills，也想查一查，Android 那些修改到底参考了什么。

Android 代码中有几个地方需要整理：网络层直接写中文错误提示，固定颜色又和资源文件重复。后面还要写 Go 和前端，准备把开发、重构和测试用得上的规范找一找，改代码时有个依据。好用的 Skills 也得在项目目录里留一份，免得 Ghost C 盘后又要重新找。

一、回顾任务

1.1 查看是否使用 Skills

之前做过原型对照、构建和测试，如果有些步骤已经稳定下来，就可以整理好留着，下次直接接着用。

复制代码

咱使用了这么久，有没有成型的skills呢？还有是否有一些好的skills在项目中可用

当时还没有成型的项目专属 Skill，不过原型对照和构建校验已经有了一些记录。整理这些现有材料，比重新写一份空泛的规范更合适：把步骤、适用版本和遇到过的问题记清楚，下次才能用得上。

1.2 修改代码需要依据

功能改动可以对照需求，代码怎么组织、错误怎么处理，也应该有参考的规范。

复制代码

有没有使用网上比较好的skills？修改代码我也不建议完全没依据的乱改吧

列出的几种 Skill 各有用途，是否适合当前项目，还得看需求和代码。最想弄清楚的还是这次修改为什么这样做，不能只给一个 Skill 名称就算有了依据。外部 Skill 要读原始 SKILL.md，核对参考文件、脚本、依赖、许可证和版本，再决定能否用在当前项目。

1.3 把验证过的 Skill 留在项目里

找到合适的 Skill 后，还得考虑怎么保存。C 盘时不时会恢复，只装在用户目录里，用过的东西很容易跟着丢掉。

r 复制代码

我的建议有两点：1、具体的项目开发过程中，能使用skills尽可能使用，要做到修改有依据 2、如果实践觉得好的skills最好备份一份在skills，因为时间长了，我可能会清掉c盘，沉淀下来的好用的skills，可以保留一份在skills中。也可以在skills中保留一份使用的规范

当时先把使用与备份约定写进了 E 盘项目，网上找到的 Skill 暂列为候选。候选先记下，核对来源、固定版本、许可证、依赖和适用范围；在项目里用过，确认合适后，再标记为已验证。C 盘以后可能用 Ghost 恢复，所以不能只留一份在用户目录或插件缓存里。

1.4 回看 Android 修改：当时依据是什么

代码已经在那里了，但为什么选这个方案、参数是怎么定的，还需要翻记录确认。

复制代码

现在回顾一下android的修改，以哪个为依据呢？技术实现的方案

已检查的五个未提交代码文件中，有几项能对应到原始反馈或界面要求；图片压缩参数等细节的依据还不够完整，整套测试也未完成。这些地方还需要补查，暂时不能认定都经过了充分验证。

1.5 Go 和 Android 的规范从哪里找

做 Go 和前端时，也希望有合适的规范可查。先确认实际用的框架和版本，再看已有 Skill 是否适用，缺什么再补。

go 复制代码

做到有法可依，我希望无论是go还是android，修改最好能优先查找一些好的skills，然后按skills的约束来进行修改。做到有法可依，不是随便改的，还有重构的skills，最好也要有所体现。

找到的规范先与项目技术栈和现有写法对照。重构还得确认哪些行为要保持，不能只按"减少重复代码"下结论。

1.6 现有项目的重构依据

复制代码

我看qoder有harness openspec之类的，咱有没有类似的,现在项目是在原有代码上修改，所以重构应该算重大指导，而如果是新的项目，最好有一些指导。

Qoder 的 harness、OpenSpec 等工具也值得了解一下，看看是否适合当前项目。现有项目需要先保护已经可观察到的行为；重构时，要明确哪些行为保持不变。新项目则可以在动手前定下目录、接口、测试等基本约定。两种场景都不适合套同一份模板。

二、回归项目

2.1 Android 修改依据

把原始需求、代码和测试记录对应起来，看看哪些改动有依据，哪些地方还缺记录。

复制代码

回到我们已修改的android代码，我想知道当时修改是以哪个为依据

当前代码可以用来检查风险，但未必能还原当初每项决策的原因。审查结论不能装作历史事实。

2.2 先做代码审查

历史记录不全，那就先审现在的代码。范围定在 app 模块，把重复逻辑、职责划分和不合理的写法找出来，再考虑怎么改。

复制代码

算了，你查不到以前更新，但可以分析一下android的源码，我们来codeview一下，总结一下有没有是重复代码，有没有是可以优化的代码，有没有写的不规范的代码，因此我想要有skills为约束的。

先把审查范围说清楚，避免把整个 Android 仓库都算进来。

2.3 只审 `app` 模块

复制代码

只审，app中的

这一步只审 app，先把问题记下来，代码和 Skill 文件暂时不动。审查结果需要给出具体位置、现有行为、风险和判断依据，后面才方便逐项核对。发现重复代码，不等于立刻抽公共方法；要先确认是否承担同一业务规则。说某处"不规范"，也应说明它与项目约定或框架惯例的关系，而不是只给一个好坏判断。

2.4 Android Studio 的 JDK 配置

Android Studio 需要使用 JDK 21，本机已有 D:\Program Files\Java\jdk-21.0.1。这类问题表面上是改路径，实际验收应看 IDE 能否识别 JDK、项目能否正常构建。找到安装目录不等于配置已经生效。

复制代码

现在android studio中jdk21，我在D:\Program Files\Java\jdk-21.0.1中有，修改一下，保证androidstudio可使用

JDK 路径改完，还要在 Android Studio 里同步配置、检查构建结果。只看到配置文件变了，暂时还不能判断项目能否正常构建。

2.5 HTTP 错误提示放在哪一层

rust 复制代码

难道android编写没有规范，怎么这种代码到处飞？ val reason = when(response.code) {
                    401 -> "登录已失效，请重新登录"
                    404 -> "动态已删除或你已无权查看"
                    413 -> "图片过大，请选择较小图片"
                    429 -> "操作频繁，请稍后再试"
                    503 -> "服务器暂不可用，请稍后重试"
                    else -> "请求失败（${response.code}）"
                }

这段处理在网络层就把 HTTP 状态码转成了中文提示，到了界面层再直接显示。切换语言时，这些提示仍然是中文；同一个 404 出现在图片、列表或动态请求中，含义也未必一样。

准备调整为网络层保留状态码和服务端错误标识，界面层根据操作场景选择字符串资源。正式改之前，还得核对每个调用点，确认不同请求需要显示什么提示。

2.6 代码要留给人读

复制代码

写代码完成任务固然重要，最重要的难道不是人读吗？重构一书就有明确说明。我让你写代码我还是希望能有一些规范，而不是为了完成任务而完成任务

代码以后还要继续改，名称和分支最好能让人看懂用意，出了错也能找到处理路径。减少行数不是重构的目的，修改后还要确认原有行为没有变。

2.7 为以后的重构找依据

复制代码

这也是我要你写代码一定要找skills的原因，做到有法可依。现在的任务是先找一些比较好的skills，注意两点：1、以后编写尽可能按这些行业内好的skills规范编写，2、以后我要重构时的一个依据

找重构 Skill，是为了提前说明什么行为必须保留、改动要怎样验证。Skill 只能提供检查思路；哪些逻辑该合并，还得看项目里的实际调用。

2.8 固定颜色该不该写在代码里

scss 复制代码

private val ink = Color.rgb(11,27,51)
private val navy = Color.rgb(10,42,102)
private val blue = Color.rgb(37,99,235)
private val dim = Color.rgb(124,137,166)
private val page = Color.rgb(246,248,252)  这种一般情况，难道不是写在color.xml中？还是现在都这样编写？

这几个固定色值已经和 colors.xml 里的颜色重复了。尤其是 colorAccent 有夜间取值，代码里的 blue 却一直用日间颜色，切换主题后就可能不一致。

这些地方可以先复用现有颜色资源，再按文字、品牌色、背景等用途整理命名，检查夜间效果。运行时计算出来的颜色则另作处理，不需要为了统一形式全部搬进 XML。

2.9 从掘金文章查找候选 Skill

测试和重构的规范也要一起准备。错误处理放在哪一层、重复资源怎么整理、改动后怎么验证，都需要具体的做法。

ini 复制代码

https://juejin.cn/post/7636555069219962907?searchId=20261101082948EF63EAA0F8F046370A4C
有些skills，看下是否有可用的

这篇文章先当查找线索。具体用哪个 Skill，还得看原文件、适用范围和项目当前的写法。

2.10 前端 Skill 也要按项目筛选

ini 复制代码

https://juejin.cn/post/7598807837868539930?searchId=20261101082948EF63EAA0F8F046370A4C 前端skills，后面我还会编写前端代码，也要先按skills规范

以后做前端或切换其他技术栈，先确认项目实际用法，再核对原始 Skill 的维护状态、依赖与适用范围；实践过的内容再进入项目备份。

2.11 测试也需要规范

复制代码

最好是能找一些开发规范，约束，包括测试，也要有规范的，专业开发的相关的东西来规范ai，这样才能生成合格的代码。

开发规范不能只管代码怎么写。功能修改、缺陷修复和重构各要验证什么，也应提前定好，交付时写清实际跑过的检查。

2.12 先准备规范，以后按任务使用

r 复制代码

现在都是一些前期准备工作，前面的暂时不改，但以后的，还是要尽可能的增加skills，做到有法可依，有法必依。
如果能提取规范并保存下来，我以前是直接给出我的规范，但我的规范也不一定是对的，还是每次（切换语言）尽可能先走skills（找网上比较好的），然后再按skills，或者一些成熟的规范，如java有阿里的规范，再进行编写。不能随便瞎飞。还有前面说过的尽可能在skills目录中有备份，万一ghost c盘后，还有

这一步仍属于准备工作：不因为找到了规范，就把此前的 Android 代码一次性改掉。以后有具体修改任务时，再按影响范围决定方案与验证。对确实有保留价值的 Skill，备份在项目 skills 目录，记录来源和版本，避免 C 盘恢复后只剩一段失效的引用。

三、以后怎么执行

以后交付修改时，希望能把这些事情说清楚：改的是哪个模块、原来怎样运行、期望怎样变化；依据来自哪里；为什么采用这个方案；做了哪些验证；还有什么没有确认。功能修改、缺陷修复和保行为重构应分别写清验收方式。

这不要求每次小改动都写长文。风险越高、影响的模块越多，方案就应越具体。简单修改可以简洁，但不能省掉关键事实。发现原有规范不适合当前项目，也可以修订，只要把原因留下来。

小结

准备先把合适的开发规范和 Skills 留下来。下次再改 Android、Go 或前端代码，先按项目情况查这些约定，再看具体怎么做。用着不合适的规则可以调整，但要记下原因，免得下一次又重复讨论。

Android 里提到的几处问题，后面还要回项目逐项处理。重构改了哪些行为、测试跑到了哪一步，到时再接着记录。

用 Codex 改代码，依据是什么？