最新

我搜索了“地狱火导弹速度”（顺便说一句，根据维基百科[1]，大约是 995 英里/小时） 显然，这以及我的搜索历史以某种方式触发了服务条款违规。 我只是在观看了 Hank Green 关于最新 UFO 视频的视频后感到好奇。 [1] https://en.wikipedia.org/wiki/AGM-114_Hellfire

以下是我给 Claude Code CLI 和 VSCode 代理的关于我的 TS 项目的提示： ``` 我修改了作业的创建方式的类型签名和行为。之前，作业定义创建接受一个批处理参数（从队列创建）。现在它直接接受队列，是异步的，需要在创建时传入 databaseClient（而不是在执行批处理时）。它不再返回任何内容——这没关系，因为结果只用于日志记录——现在已经为我们完成了，所以我们不必担心。我们可以重构代码库以使用新的 JobDefinition.create 吗？请删除残留的“Job created”日志。 执行此任务，且仅执行此任务。如果你看到一些不相关的内容，你认为需要重构——请勿修改它。仅执行与此任务直接相关的操作。 ``` 所以有两个指示： 1. 执行任务 2. 不要做与任务无关的事情（在后续尝试中因沮丧而添加） 我的经验： 代理流程开始得很好——它找到了所有需要更改的文件并开始进行编辑。 大约在第 5 个文件时，我注意到除了请求的重构之外，它还开始重新排序 `JobDefinition.create` 方法的对象键。虽然在语义上是无操作的，但这非常令人沮丧，因为它使 diffs 难以审查。 稍后，它开始修改它不满意的日志消息，最终完全失控，并向我的函数定义添加了它*认为*它们需要的参数（引入类型/运行时错误）。 VSCode 会定期暂停并要求确认才能继续。每次我都会利用这个机会重新提示代理，让它专注于目标： 我：“停止跑题——停止重命名变量，重新排序参数。只做任务告诉你的事情，仅此而已” 代理：“你完全正确。对于跑题，我深感抱歉。让我只专注于任务：重构 JobDefinition.create 调用以使用新的签名并删除残留的“Job created”日志” 但每次这种不良行为都会在一段时间后再次出现。 我不确定我做错了什么。我假设这种机械的猴子工作对于基于代理的工作流程来说是小菜一碟——但它却一直失去连贯性。 我最终回滚了所有更改，因为我对生成的代码的质量完全没有信心。 对于这堆文字，我深感抱歉，但我对浪费的时间感到非常沮丧，并且非常想知道我做错了什么！ 提前感谢！

我在这个平台上读到过一篇很有意思的帖子，内容是：在做带回家做的项目时，不一定要太快完成，因为如果你在截止日期或招聘人员招聘周期的后期提交，你会有更大的机会进入下一轮。<p>但另一方面，如果你真的对这个职位感兴趣，你会很快完成它。<p>我觉得这很有意思，因为如果给定了具体的截止日期，比如两周——我想如果我很快提交，会显示出我的主动性，比如展现积极性等等。但“听起来”等待并稍后提交（不是在截止日期，而是在50%-75%的时间点）似乎是一个更聪明的做法。<p>你可能会认为，糟糕的作品 == 被招聘人员拒绝，或者我低估了我的作品的竞争力，但这确实感觉非常“元”，反映了当今的招聘模式。