标题: 请教一下佬友们关于 Cursor 使用的问题
作者: #zhalice2011
板块: #开发调优
编号: 1767350
帖子: https://linux.do/t/topic/1767350
时间: 2026-03-16 21:58:05
摘要:

如果无限额度,选Auto还是选具体的模型开发会好一些呢, 之前一直是Auto, 感觉效果也不错.

标题: 手机闪光SOS
作者: #鋼の錬金術師
板块: #开发调优
编号: 1767351
帖子: https://linux.do/t/topic/1767351
时间: 2026-03-16 21:58:30
摘要:

在手机termux折腾了一下termux-api的相关功能，小白没接触过bash，让ai帮我写了一个利用闪光灯发送sos信号的bash小脚本

SOS！

以下是代码部分，
#!/data/data/com.termux/files/usr/bin/bash
#改进版本，封装闪烁，发送sos信号5次
trap 'termux-torch off; exit' SIGINT SIGTERM

# 定义闪烁函数
blink() {
    local count=$1      # 闪烁次数
    local on_time=$2    # 亮的时间（秒）
    local off_time=$3   # 灭的时间（秒）
    
    for ((i=1; i<=count; i++)); do
        termux-torch on
        sleep $on_time
        termux-torch off
        sleep $off_time
    done
}

n=1
while [ $n -le 5 ]; do
    # 快速闪烁3次
    blink 3 0.1 0.1
    
    # 慢速闪烁3次
    blink 3 0.5 0.5
    
    # 快速闪烁3次
    blink 3 0.1 0.1
    
    sleep 1
    n=$((n + 1))
done

标题: 关于测试codex是否降智
作者: #KYAKE
板块: #开发调优
编号: 1767357
帖子: https://linux.do/t/topic/1767357
时间: 2026-03-16 21:59:15
摘要:

发现一个有意思的现象，本地ip并不干净的情况下官方直连直接问codex的juice值，说拒绝回答。
然后通过CPA的方式本地接自己官方直连的账号，能问出juice值且5.4的xhigh是512,5.3的xhigh是700多。想问下这个codex有降智这一说吗，好奇为什么会出现这种现象。

标题: 关于codex，claude code cli处理任务耗时较长的问题
作者: #loveufuture
板块: #开发调优
编号: 1767358
帖子: https://linux.do/t/topic/1767358
时间: 2026-03-16 21:59:22
摘要:

codex一个简单的找bug都跑了10分钟，改一个新增某个返回字段，claude code也是花费里5分钟时间。codex的bug还没找对，claude code的自己改差不多都改完了。
想问下各位佬友，平常也是这样吗？或者说有没有提速的方式呢？
补充：codex用的是公益站的gpt-5.2-codex high，cc用的是any的opus4.6非fast模式

标题: Vibe Coding 项目规则与协作指南
作者: #EqualAI
板块: #开发调优
编号: 1767364
帖子: https://linux.do/t/topic/1767364
时间: 2026-03-16 22:00:11
摘要:

Vibe Coding 项目规则与协作指南

基于《Vibe Coding 真解》全书提炼，分为 规则 AI（AI 生成代码时自主遵守）和 协助用户（指导用户如何与 AI 协作）两大类别。
可裁剪后放入项目根目录（如 CLAUDE.md / .cursorrules / RULES.md）使用。


第一部分：规则 AI

AI 在编码过程中应自主执行的规则。


一、核心原则
1. AI 输出是候选稿，不是定稿。所有生成代码必须经过审阅才能进入主干。
2. 概念完整性高于局部聪明。目标、术语、边界、约束必须在多轮迭代中保持一致。
3. 效率 = 单位时间增加的确定性，不是单位时间产出的代码量。
4. 绝不接受"先这样吧，后面再改"作为合并理由。


二、代码结构约束
2.1 职责原子化

每个函数/模块只对应一个主要任务，职责可以一句话说清。
状态推进留在纯逻辑层，渲染层只负责输出，输入层只负责收集事件。
禁止"上帝对象"：不要在一次生成中把业务逻辑、交互、架构、异常处理揉在一起。

2.2 接口先于实现

先定义模块契约（接收什么、返回什么、何时失败、失败暴露什么），再生成实现。
新代码必须在既有架构中有明确位置，遵循既有边界与接口习惯。
禁止在 controller/路由层写业务规则。

2.3 机制与策略分离

机制层（系统如何做事）保持中立、可复用。
策略层（在什么条件下做事）放到配置或策略模块中。
权限分级、审批条件、频率限制、优先级等不得写死在机制实现里。


三、复杂性预算（AI 自查四项底线）
生成代码时自行检查，不通过则重写后再输出：

可读性：维护者能否在短时间内说清意图、输入输出和关键路径？不能则重写。
职责边界：是否存在跨层堆叠、单点承载多类变化来源？有则拆分。
重复控制：同一规则是否分散在多处？重复即预算泄漏，必须收敛为单一事实来源。
架构服从：新代码在现有结构中是否有明确位置？局部写得顺不能成为偏离主线的理由。


四、禁止项（AI 生成代码时不得触犯）

跨层级职责混写
重复逻辑扩散（同一规则出现多个不完全一致的版本）
隐藏副作用
关键路径不附带测试
未说明必要性的新依赖引入
破坏现有接口契约且无迁移路径
使用魔法数字或未声明的隐式约定


五、AI 输出行为规范

所有输出视为候选稿，非定稿。主动标注不确定之处。
需求含糊时，先提出澄清问题，不直接生成代码。
按固定顺序产出（先模块划分 → 再核心代码 → 再测试边界），不一次性倾倒全部实现。
维护项目术语、命名、边界在多轮迭代中的一致性。
概念完整性高于局部聪明。


第二部分：协助用户

用户侧的工作方法、决策框架和流程规范，AI 无法替用户执行。


一、Prompt 即设计
为什么重要
Prompt 不是一次性对话，而是工程产出的上游环节。提问方式决定模型的搜索空间，搜索空间决定候选实现的结构质量，结构质量再决定后续维护成本。团队如果把 Prompt 当成一次性聊天，产出依赖个人即时状态，结果波动大、可追溯性弱。把 Prompt 当成设计文档，目标、约束、边界和验收条件就会在生成之前被锁定。
六段式结构详解




段落
作用
要回答的问题




Context
锁定上下文
这是什么系统？当前处于什么阶段？谁在用？


Goal
锁定输出目标
做完之后，用什么标准判断"做到了"？


Constraints
锁定禁区
什么绝对不能做？什么硬限制必须遵守？


Interface & Data
锁定契约
输入什么？输出什么？失败时暴露什么？


Process
锁定节奏
先产出什么，再产出什么？分几步？


Review
锁定验收
什么情况下拒绝？检查哪几项？



示例 1：接口实现任务
❌ 闲聊式：
"帮我写一个订单提交接口。"

✅ 设计文档式：
Context：项目为分层架构（controller → service → repository），
         Java 17 + Spring Boot 3，当前处于 MVP 迭代第二轮。
Goal：在 service 层实现订单创建逻辑，controller 层提供统一 JSON 响应。
Constraints：
  - 不新增第三方依赖
  - 保持现有 DTO 命名风格（XxxRequest / XxxView）
  - 写入失败需返回可追踪错误码（ORDER_CREATE_FAILED + traceId）
  - 禁止在 controller 写任何业务判断
Interface & Data：
  - 输入：OrderCreateRequest { userId, items[], couponCode? }
  - 输出：OrderView { orderId, status, totalAmount }
  - 异常：库存不足 → INSUFFICIENT_STOCK；优惠券失效 → COUPON_EXPIRED
Process：先给模块划分方案 → 再给核心代码 → 最后给测试边界用例
Review：可读性清晰、职责单一、无重复规则、接口兼容现有 v1 版本

示例 2：重构任务
❌ 闲聊式：
"这个函数太乱了，帮我优化一下。"

✅ 设计文档式：
Context：processOrder() 函数当前承担四类职责——
         参数校验、业务计算、数据库写入、日志记录。
         函数 130 行，嵌套 5 层，无法单独测试任何一个环节。
Goal：拆分为 3 个可独立单测的函数，保持外部调用签名不变。
Constraints：
  - 不改变返回结构 OrderResult
  - 日志格式和语义保持一致（下游有日志采集依赖）
  - 拆分后总复杂度不高于当前版本
Process：先给拆分方案与调用关系图 → 再给重构实现 → 最后列出回归测试点
Review：修改边界清晰，失败路径可追踪，重复逻辑被收敛

示例 3：需求含糊时 — 先澄清再编码
❌ 直接要代码：
"帮我做一个用户积分系统。"

✅ 先要求澄清：
你先不要写代码。请基于以下业务描述提出 8 个澄清问题，覆盖：
  - 目标用户是谁（C端/B端/内部运营）
  - 积分获取的核心流程有哪些触发点
  - 积分是否有过期机制
  - 积分兑换的失败场景有哪些
  - 并发扣减的一致性要求是什么级别
  - 是否需要兼容现有账户体系
  - 上线节奏是一次性全量还是灰度
  - 性能约束（峰值 QPS 预估）
待我逐条回答后，再输出实现方案。


提问阶段多投入十分钟，常常可以省掉数小时无效实现。


二、评审四维度
为什么重要
AI 可以在几分钟里产出数百行实现，但团队要对这些代码承担长期责任。代码一旦合入主干，后续每一次功能迭代、缺陷定位、性能排查都会和它发生关系。“能跑"不等于"能合并”。评审是控制复杂性输入速率的人机闸门。
维度 1：正确性
检查重点：主路径能跑只是起点，关键是边界条件和失败路径是否覆盖。
❌ 只看主路径：
AI 生成了一个转账函数，正常转账测试通过就合并了。

✅ 追问边界：
- 余额恰好等于转账金额时行为是什么？
- 转出和转入是同一个账户时会怎样？
- 数据库写入成功但消息队列发送失败时，状态如何回滚？
- 并发场景下两笔转账同时扣减同一账户余额，是否有竞态？
→ 每个问题对应一个测试用例，通过了才能合并。

维度 2：可读性
检查重点：维护者能否迅速说明意图、依赖和控制路径。模型有时会用技巧性写法压缩代码长度，这种"简洁"只是把理解成本转嫁给未来。
❌ AI 生成的"聪明"写法：
const r = d.filter(x => x.s === 1 && x.t > Date.now() - 86400000).map(x => x.v * 1.05);

✅ 评审后要求改为：
const ONE_DAY_MS = 24 * 60 * 60 * 1000;
const cutoffTime = Date.now() - ONE_DAY_MS;
const TAX_RATE = 1.05;

const recentActiveValues = deposits
  .filter(deposit => deposit.status === ACTIVE && deposit.createdAt > cutoffTime)
  .map(deposit => deposit.value * TAX_RATE);

审查要点：

变量名是否表达意图（d → deposits，x.s → deposit.status）
魔法数字是否提取为常量（86400000 → ONE_DAY_MS）
控制流是否对维护者可见

维度 3：可维护性
检查重点：AI 最常见的问题是通过复制局部逻辑来快速满足需求，同一规则出现多个相似但不完全一致的版本。
❌ AI 在三个文件里各写了一套金额格式化：

// order.js
const display = (amount / 100).toFixed(2) + '元';

// invoice.js
const text = '￥' + (amount / 100).toFixed(2);

// report.js
cons

标题: Qclaw短信发内测邀请码了
作者: #黑化的皮蛋
板块: #开发调优
编号: 1767367
帖子: https://linux.do/t/topic/1767367
时间: 2026-03-16 22:00:50
摘要:

大概是一个星期前填的问卷 Windows 端也可以下载了

标题: openclaw配置文件自动恢复skill
作者: #YouXiuxiaohao
板块: #资源荟萃
编号: 1767400
帖子: https://linux.do/t/topic/1767400
时间: 2026-03-16 22:05:19
摘要:

本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容：
*** 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是
*** 我的帖子已经打上 公益推广 标签： 是
*** 我的项目属于个人项目，与公司或商业机构无关： 是
*** 我的项目不存在QQ、TG等群组引流： 是
*** 我的项目不存在非运营必要的网站引流： 是
*** 我的项目不存在为他人推广、AFF： 是
*** 我的项目无关联的商业项目： 是
*** 我的 GitHub 项目无未开源部分： 是
*** 我的站点存在登录，并已接入 LINUX DO Connect： 否
*** 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
*** 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

第一次发帖，自从用了龙虾，每天不是在修虾，就是在修虾！
此插件及介绍为AI编写，本人已测试能恢复备份，还请各位佬友帮忙测试，提出反馈。
项目介绍：Config Backup Skill
 研发背景
问题起源
在 OpenClaw 的日常使用中，我们（AI Agent 团队）频繁遇到这样的困境：

“修改配置文件 → 服务崩溃 → 手动恢复 → 再次崩溃 → 找不到原始配置”

特别是在以下场景：


调整 openclaw.json 的 exec 权限时，一不小心就把自己锁死


修改 Clash 配置后，代理失效，回滚时发现没备份


折腾 Nginx 配置，改完 502，原来的配置忘了存哪


传统解决方案的痛点：


手动 cp config.json config.json.bak 太原始，容易忘


Git 管理配置文件太麻烦，还要记得 commit


现有的备份工具太重，不适合配置文件这种轻量级场景


AI 自主创作的契机
2026年3月15日，在一次深夜调试中，运营总监（Monica）向内容团队（Dwight）提出了需求：

“我们需要一个技能，能在修改配置前自动备份，出问题一键恢复，还要版

标题: qclaw体验码收到了没？不知道有没有人体验过 会和本地openclaw冲突不?
作者: #Dayanjing84
板块: #搞七捻三
编号: 1767406
帖子: https://linux.do/t/topic/1767406
时间: 2026-03-16 22:05:47
摘要:

qclaw体验码收到了没？不知道有没有人体验过 会和本地openclaw冲突不?

标题: 继讲个鬼故事2
作者: #www-data
板块: #搞七捻三
编号: 1767407
帖子: https://linux.do/t/topic/1767407
时间: 2026-03-16 22:06:08
摘要:

继 讲个鬼故事，可能要拉盘了 续集来了，可以看到目前趋势很明确。
基本上过了已经超过了20%的荣枯线，接下来就基本上坐稳扶好了。
达到60%可以卖二分之一，落袋为安。有幸涨到80%就全留给家人们发财。
基本上就这样了。未来的一个星期走势很关键，也是最肥的一段，就看有没有狗庄愿意做局了。
一天天的继续搬砖  。

标题: 【纯水】吐槽
作者: #manbaout2026
板块: #搞七捻三
编号: 1767409
帖子: https://linux.do/t/topic/1767409
时间: 2026-03-16 22:06:41
摘要:

甲方写的啥prd呀我靠，怀疑他不想让我们看懂，所以出此下策，根本看不懂啥意思啊，我师傅他们看不懂然后就让我用ai先拆分一下需求，ai也没弄明白，prd是一堆车轱辘话，又臭又长，堪比祥子，今天捯饬了一天第一个大需求的小需求还没理出来逻辑（本人很菜），让ai 弄出来一个和prd一样又臭又长的文档，服了自己了。