代码生成之后:对工程师而言依然重要的技能
当模型编写代码时,评判标准会转向规格要求、审查流程、架构设计以及验证习惯。
可将此内容视为《AI能帮你写代码,那你现在该做什么?》一文中理念面向操作人员的重构版本:清晰的阶段划分、有序的代码模块,以及能在交接过程中保留的恢复说明。将概览视为可量化的界面来使用效果最佳,在扩大范围之前,先记录一份完美的操作日志、一个故障案例以及回滚说明。应将此阶段视为输入与经过验证的输出之间的契约,为相关成果命名、明确成功标准,绝不允许出现无声的半完成状态。
代码的成本正在降低
由于代码成本日益降低,因此在修改代码之前应先明确输入参数、该步骤的负责人以及终止标准。操作人员应当能够从已知的检查点重新运行该步骤,而无需猜测隐藏状态。除了功能测试结果外,还需记录执行时间以及令牌或查询成本。提前了解这些成本信息,可避免在从演示环境过渡到共享环境时出现意外费用。只要预算允许,就应在持续集成过程中使用固定配置而非真实的付费 API 来添加能够测试关键路径的烟雾测试。
Add JWT authentication.
Create login and refresh-token APIs.
Add PostgreSQL persistence.
Write integration tests.
Run the test suite.
Fix failures.
Anthropic 正在为我们指明发展方向
Anthropic正在为我们指明发展方向,因此在修改代码之前应先明确输入参数、各步骤的负责人以及终止标准。操作人员应当能够从已知的检查点重新运行相应步骤,而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置,这样操作人员无需查看整个系统结构即可进行审核。 只要预算允许,就应在持续集成过程中通过测试用例而非真实的付费API来执行关键路径的冒烟测试。
Is the architecture correct?
Is authentication secure?What happens under 10,000 requests?Can this transaction fail halfway?Will this leak memory?What happens when Redis is unavailable?What happens when the database is slow?Did the AI introduce a race condition?
随后发生了更重大的事情
在修改代码之前,应先明确输入参数、该步骤的负责人以及终止标准。操作人员应当能够从已知的检查点重新运行该步骤,而无需猜测其中的隐藏状态。需同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误处理都是产品不可或缺的部分,而非后续才需要补充的功能。只要预算允许,就应在持续集成过程中使用测试用例来执行关键路径的冒烟测试,而非依赖实际的付费 API。在修改代码之前,应先明确输入参数、该步骤的负责人以及终止标准。操作人员应当能够从已知的检查点重新运行该步骤,而无需猜测其中的隐藏状态。应将这一阶段视为输入与经过验证的输出之间的契约,为相关成果命名、定义成功标准,并杜绝默默完成部分任务的情况。
开发者可能犯的最大错误
在研究“开发者可能犯的最大错误”时,首先写下相关规范:所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况,可避免从演示环境过渡到共享环境时出现意外费用。 编写一份简短的操作手册:说明如何轮换密钥、如何清空队列,以及如何回滚上一次的数据导入操作。
@GetMapping("/users")
public List<User> getUsers() {
return userRepository.findAll();
}
那么开发者现在应该学习什么呢?
在探讨“开发者现在应该学习什么?”这一问题时,首先需明确契约内容:所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持透明可追溯。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一处,这样操作人员无需查看整个系统结构即可进行审计。 编写简短的操作手册:说明如何轮换密钥、如何清空队列,以及如何回滚上一次的数据导入操作。
Write this.
Refactor this.
Explain this.
Test this.
Fix this.
Convert this.
Don't build it this way.
Here's why.
Here's the simpler architecture.
Here's the failure mode you missed.
Here's what we should measure in production.
AI并不能取代思考的能力
即便使用人工智能,也依然需要思考,因此首先要写明契约内容:所需的输入参数、成功标志,以及部分失败时会发生什么。这样的清单能确保后续的代码修改保持透明可溯。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理方式都是产品本身的一部分,而非后续才添加的完善措施。 编写一份简短的操作手册:说明如何轮换密钥、如何清空队列、以及如何回滚上一次的数据导入操作。 即便使用人工智能,也依然需要思考,因此首先要写明契约内容:所需的输入参数、成功标志,以及部分失败时会发生什么。这样的清单能确保后续的代码修改保持透明可溯。 将这一阶段视为输入与验证后输出之间的契约。为相关产物命名,明确成功判定标准,绝不允许出现无声无息的部分完成情况。
Prompt → Copy → Commit → Next task
新软件工程师
将新来的软件工程师视作可度量的对象,才能让工作更高效。在扩大范围之前,先记录一份优秀的测试用例、一个故障案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况,就能避免从演示环境过渡到共享环境时出现意外账单。锁定依赖版本,并记录用于运行演示的镜像摘要。可重复性远胜于仅凭团队经验。
假如你是一名开发者
如果将开发者工作视为可度量的对象,会更易于处理。在扩大范围之前,先记录一个成功的案例、一个失败案例以及回滚说明。 应将配置与应用程序代码分开。环境文件、密钥存储和功能开关应集中存放,以便操作人员无需查看整个系统结构即可进行审计。 锁定依赖版本,并记录用于运行演示的镜像摘要。可重复性比经验知识更重要。
运营检查清单
在制定运营检查清单时,首先明确契约内容:所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。
优先选择小型、可测试的单元,而非庞大的脚本。当某个步骤失败时,故障应能指向单一责任点,而非复杂的流程链。
编写一份简短的操作手册:说明如何轮换密钥、如何清空队列、以及如何回滚上一次的数据导入操作。
同时记录正常流程与故障恢复流程。重试机制、人工审核环节以及死信处理都是产品不可或缺的部分,而非后续需要补充的功能。
在预算允许的情况下,使用测试数据而非真实的付费 API,在持续集成过程中添加用于检测关键流程的冒烟测试。
将配置信息与应用程序代码分开。环境文件、密钥存储以及功能开关应集中存放于一个位置,以便操作人员无需查看全部架构即可进行审计。
在升级技术栈之前,先锁定各版本,为关键流程记录标准操作流程,并确认回滚步骤。共享环境需要设置速率限制、租户验证机制,以及明确的密钥轮换负责人。与其追求华丽的临时演示,不如注重扎实的可靠性。
关于34004c5d2824的批处理说明:不要将提供者密钥放入代码仓库,为每个会话设置令牌上限,并将转录内容存储在评估测试文件旁,以便后续模型更换时保持可比性。