最近发现ai改代码挺好用，同时也发现一个问题！同一个会话对话越多ai理解出错和内容丢失概率越高，试着尝试新建会话确实理解能力变强出错概率低了，但是前期准备阶段需要让ai识别项目目录读取内容，等待时机很漫长。所以各位解决代码问题是一个问题一个会话吗！
我来写一个我认为的 CC 最佳用法 我看很多人每天 CC 用的很不舒服每天喊 CC 降智，然后我又是一个 Python 哲学的信奉者（凡事有最佳实践），总结一下用 CC 四个月的体验。基本上各路大佬都提过，我只是一个总结者。 我只总结最重要的三点，只记住这三个最简单的点让你 CC 智力直线上升： 1、除非在 planmode，永远不要纠正 CC。如果 CC 做错了，直接 clear → git reset ->修改原始 prompt 叫他不要犯这个错。不然你去纠正他的话，你就会收到典中典的“您说的对”。 2、永远不要使用 /compact。你就当没有这个命令，如果一个需求执行到 context 满了还没完成，把这个需求拆成两个。 clear → git reset → 只做第一个需求。 3、如果一个需求三轮对话还没完成，重新来，context 用到 60% 就差不多了。想清楚你要干什么，clear → git reset → 重新编辑 prompt 。 所以使用 cc 的流程大体是这样： 1、如果是简单需求，一次性描述清楚，让 CC 在两轮对话内完成，如果它做错了。重新来（彻底重新开始，不要纠正它让他改错，不要！），把避免这个错误放到原始 prompt 后面。如此反复直到你在三轮对话内完成这个需求 2、如果是复杂需求，使用 planmode，你可以在里面指出 CC 的错误，反复商量，让它修改 plan。最后让他一次性完成。注意，要保证他在完成时还有 10%左右的 context 可用。如果 context 不够了，拆分你的需求，直到可以在一个 context 内完成。 一句话总结：CC 开发团队说过的，错了不要改，直接重新来。没错，绝对是正解。 就这么简单。 说实话我在 CC 出 bug 的那一周之外，很少感觉 CC 降智。降智确实存在，但影响远不及使用方法错误导致的降智。很多人都说 CC 在用完 60% 的 context 之后能力会急剧下降，我的感受也是如此。 我在 88code 后台看缓存命中的时候，经常看到一个 session 压缩了几次还在继续用的，这个时候 cc 的智商已经完全不在了，降智是必然的。 欢迎评论区亮出你的使用技巧 Comments 是的，三轮对话原则也保证了你不会跟他扯皮。直接 clear 重新来，别犹豫。就算你没想好 prompt 怎么改，直接重来一遍，也可能就对了 一个需求尽量在一个session内完成，并且保证足够的上下文可用，完不成了直接拆分需求。要不就会越干越乱，特别是上下文一长或者压缩之后，前面的功能出问题再让他改，就会出现很多临时变量，而且有时候改的还不对。 cc 是第一次效果最好, 你再叫它改 没有提升。 codex 是第二次 第三次 会有提升。 后面就没什么提升了 。 永远不要试图去纠正任何人(AI) 成年人只需要做选择(to do or not to do) 要懂得及时止损(clear+git reset) 不合适的直接下一个(session) 不要钻牛角尖, 尝试撞南墙(compact), 不然你只对得到敷衍的“啊对对对” 最好的永远不是100%, 二八定律要牢记(AI这里是4/6开) 参考链接：https://www.anthropic.com/news/how-anthropic-teams-use-claude-code 本文转载自51CTO技术栈，作者：伊风
我来写一个我认为的 CC 最佳用法
我看很多人每天 CC 用的很不舒服每天喊 CC 降智，然后我又是一个 Python 哲学的信奉者（凡事有最佳实践），总结一下用 CC 四个月的体验。基本上各路大佬都提过，我只是一个总结者。
我只总结最重要的三点，只记住这三个最简单的点让你 CC 智力直线上升：
1、除非在 planmode，永远不要纠正 CC。如果 CC 做错了，直接 clear → git reset ->修改原始 prompt 叫他不要犯这个错。不然你去纠正他的话，你就会收到典中典的“您说的对”。
2、永远不要使用 /compact。你就当没有这个命令，如果一个需求执行到 context 满了还没完成，把这个需求拆成两个。 clear → git reset → 只做第一个需求。
3、如果一个需求三轮对话还没完成，重新来，context 用到 60% 就差不多了。想清楚你要干什么，clear → git reset → 重新编辑 prompt 。
所以使用 cc 的流程大体是这样：
1、如果是简单需求，一次性描述清楚，让 CC 在两轮对话内完成，如果它做错了。重新来（彻底重新开始，不要纠正它让他改错，不要！），把避免这个错误放到原始 prompt 后面。如此反复直到你在三轮对话内完成这个需求
2、如果是复杂需求，使用 planmode，你可以在里面指出 CC 的错误，反复商量，让它修改 plan。最后让他一次性完成。注意，要保证他在完成时还有 10%左右的 context 可用。如果 context 不够了，拆分你的需求，直到可以在一个 context 内完成。
一句话总结：CC 开发团队说过的，错了不要改，直接重新来。没错，绝对是正解。
就这么简单。
说实话我在 CC 出 bug 的那一周之外，很少感觉 CC 降智。降智确实存在，但影响远不及使用方法错误导致的降智。很多人都说 CC 在用完 60% 的 context 之后能力会急剧下降，我的感受也是如此。
我在 88code 后台看缓存命中的时候，经常看到一个 session 压缩了几次还在继续用的，这个时候 cc 的智商已经完全不在了，降智是必然的。
欢迎评论区亮出你的使用技巧
Comments
是的，三轮对话原则也保证了你不会跟他扯皮。直接 clear 重新来，别犹豫。就算你没想好 prompt 怎么改，直接重来一遍，也可能就对了
一个需求尽量在一个session内完成，并且保证足够的上下文可用，完不成了直接拆分需求。要不就会越干越乱，特别是上下文一长或者压缩之后，前面的功能出问题再让他改，就会出现很多临时变量，而且有时候改的还不对。
cc 是第一次效果最好, 你再叫它改 没有提升。 codex 是第二次 第三次 会有提升。 后面就没什么提升了 。
参考链接：https://www.anthropic.com/news/how-anthropic-teams-use-claude-code
本文转载自51CTO技术栈，作者：伊风
发现变蠢了就新开
我不懂代码，但我感觉提示词的逻辑和给的文档格式很关键
最好一次性把问题描述全面了
@evolution #4 太多也不行，逻辑我感觉很关键，太多反而有时候像抽疯一样乱答
@woq #3 你字多，信你
@Newbie-rd #5 没错，ai的智商和使用者息息相关
@evolution #4 我发现对话多了，他甚至识别不到你的问题，而是给你解决之前对话的问题，再帮你解决一遍
@白纸 #8 有时候是这样，那就重开吧
关键问题放开头或结尾，因为多头注意力机制会更关注开头结尾。
中间部分我喜欢用1，2，3，4分步说明需求，并选择性用双引号或*号标注重点