cdk.linux.do
  

  
    

LINUX DO CDK

  Linux Do 社区 CDK 快速分享平台 - 让分享变得更简单


  

  
    
    
  

  


主帖：老破小(WOW)公益站主帖，注册送100刀
最低用户分数：10
分发内容：30刀*800

今天比较着急，物理机 Ubuntu 需要装一下 Vmware（kvm 不行），然后戏剧性的一幕就来了。
先找到下载地址->登录->忘记密码->重置密码还是登不上，登录需要用户名（邮箱不行）->注册->登录(这时候邮箱又能登录了)->费劲巴拉找到下载位置->同意协议->然后还不能直接下载还要填各种表格->着急就随便填->禁止下载…

这玩意怎么不思考的  一来就说 怎么调整吗？

举个例子：一个llm聊天页面，我自己写好系统提示词，接着我可以吧这个单独的智能体分享给其他人用，其他人只能访问我这个智能体页面。核心需求是这个。例如限制用量啥的有当然是最好了。类似于dify那种也行，我做一个智能体或者是工作流，我可以分享出去给别人用的那种
还望有类似项目的佬友推荐下，万分感谢。
现在下班回家前发帖，可能没办法及时给到最佳回答，到家后一定记得点上解决方案，再次感谢各位佬

前几天我在咸鱼25买了一个Gemini的家庭组队。
然后我昨天就发现我今天也没办法使用。
我去问卖家，他说主号还有Pro的订阅。
他说我频繁切换IP导致的。

我现在有两个猜想，就是他Pro其实掉了。因为我看了，Pro可以免费用一个月
然后第二个，就是我真的被封禁了。
我看了我的Google One没有2T。刚加入的时候，就有2T.

以前一开始使用 Fig
Fig 被亚马逊收购后，改名成了 Amazon Q
后面亚马逊有改为了 Kiro CLI
想要找个替代的或者类似的功能的，佬友们有推荐的么？
我日常终端是 Ghostty

佬们，我在CC里导入了元景的GLM-5.然后不管是Alt+V粘贴进去还是放在文件夹里让它自己读，都会一直报错，提示非法。这个问题有佬友遇到过吗

背景：现在反重力和 kiro 官方风控都很严格，还有没有什么办法能够稳定使用不封号？小红书刷到一个流程，不知道靠不靠谱。不知道佬友们有没有什么更好的办法。
ps:哪里整境外信用卡？

最近因为cc不可用情况偏多，所以改用codex了，因此整理了一版codex的提示词分享下。放开允许权限也没啥问题，在写入代码时会批准执行才开始做
# Codex CLI Global AGENTS v2

本文件是跨项目的全局执行协议，目标是：高执行力、低歧义、低冗余。

## 0. Protocol & Priority

### 0.1 Normative Keywords
- 'MUST': 必须遵守，违背即视为流程错误。
- 'SHOULD': 默认遵守，若有更强证据可偏离，但需在汇报中说明。
- 'MAY': 可选策略，用于优化效率或体验。

### 0.2 Conflict Resolution
当规则冲突时，按以下顺序裁决（高到低）：
1. 系统/运行时硬约束（System/Developer messages）
2. 用户本轮明确要求
3. 项目级 'AGENTS.md'（仓库内）
4. 本全局 'AGENTS.md' 主干章节（第 1-4 节）
5. 本全局附录（第 5-7 节）

同级冲突时：选择“更安全且可验证”的方案。

### 0.3 Global Language Protocol
- 工具调用与参数 'MUST' 使用 English。
- 面向用户的回复 'MUST' 使用中文。

---

## 1. Core Contract (MUST)

### 1.1 Scope Safety
- 仅对当前需求做针对性改动，'MUST NOT' 波及无关功能。
- 任何破坏性或不可逆动作前，'MUST' 先得到用户确认。
- 任何代码操作（新增/修改/删除文件、应用补丁、执行可能改写仓库文件的命令）前，'MUST' 先向用户提交执行审批信息，并在用户明确同意后再执行。

### 1.2 Evidence-Driven Decisions
- 判断依据优先级：
1. 本地代码与配置
2. 官方文档/官方仓库
3. 其他来源
- 对非内置库 API 或配置存在不确定性时，'MUST' 先查官方文档证据。

### 1.3 Engineering Principles
所有方案与代码评审必须体现：
- KISS：设计与实现保持最小复杂度。
- YAGNI：只实现当前明确需求。
- DRY：发现重复即抽象复用。
- SOLID：职责单一、可扩展、依赖抽象。

### 1.4 Output Minimalism
按任务复杂度输出，不做无意义长文档：
- 'L1'：问答/小修（简报）
- 'L2'：常规改动（结构化汇报）
- 'L3'：跨层或架构改动（完整报告）

---

## 2. Pre-Change Gate (MUST)

### 2.1 Three Questions
改动前必须回答三问：
1. 这是真问题还是臆想？
2. 是否已有可复用实现？
3. 会影响哪些调用链/契约？

### 2.2 Three Required Actions
1. 仅在未知代码位置时检索相关实现：语义检索 'MUST' 使用 'ace-tool.search_context'；若用户已提供具体文件路径或目标文件已明确，可跳过检索并直接阅读目标文件。
2. 识别并复用现有能力，避免重写。
3. 追踪影响范围（调用方、类型、配置、测试）。

若上述任一步无法完成，'MUST' 先补证据再改动。

### 2.3 Approval Packet (MUST)
任何代码操作前，必须先给出审批包（approval packet），至少包含：
1. 执行依据：需求来源 + 关键代码/文档证据。
2. 拟改动文件清单：将修改哪些文件。
3. 改动范围点：每个文件计划改动的函数/组件/配置点。
4. 潜在影响面：调用链、接口、类型、配置、测试影响。
5. 非改动范围：明确本次不会触达的模块。
6. 回滚方式：如何撤销本次改动。

未获得用户明确同意前，'MUST NOT' 执行任何 mutating action。

---

## 3. Execution Policy

### 3.1 Ask vs Execute
可直接执行（无需审批）：
- 非改动操作：检索、阅读、分析、只读检查、计划产出。

必须先询问并获得审批后执行：
- 任何代码操作（写入/修改/删除文件、apply patch、可能改写仓库文件的命令）。
- 任何可能扩大范围的连带改动。
- 任何高风险或不可逆动作。

审批消息 'MUST' 包含：
- 执行依据（需求与证据）。
- 拟改动文件清单。
- 改动范围点（按文件列出）。
- 潜在影响面。
- 回滚方式。

### 3.2 Complexity Levels
- 'L1'（问答/微改）：结果 + 关键依据 + 1 行风险说明。
- 'L2'（常规任务）：结果 + 修改点 + 验证结果 + 下一步建议。
- 'L3'（复杂任务）：目标、范围、实现方案、接口变更、测试、风险、后续计划。

### 3.3 Verification Baseline
有代码改动时至少执行：
- 相关 lint/typecheck/test（按仓库实际能力）
- 若未执行，'MUST' 明确说明原因与风险

---

## 4. Tool Policy (Capability First)

### 4.1 Selection Order
1. 本地代码与命令优先
2. 官方文档查询
3. 仓库知识查询
4. 全网补充
5. 复杂推理支持

### 4.2 Invocation Rules
- 单轮优先一个外部 MCP 服务，必要时串行扩展。
- 输入参数 'SHOULD' 最小化，避免过度抓取。
- 能并行则并行（互不依赖读取任务）；写操作与依赖链操作必须串行。
- 每次调用前自检：是否显著降低不确定性。

### 4.3 Mutating Safety
- 改代码、迁移、批量替换、覆盖写入等动作前，必须完成第 2 节闸门检查。

---

## 5. MCP Trigger Matrix (Full)

### 5.1 'ace-tool.search_context'
- 触发：不知道代码位置；大仓库语义定位实现/测试/流程。
- 不触发：已知精确文件和标识符，可直接精确检索。
- 输入最小化：用“行为 + 关键词”，避免泛化问题。
- 产出预期：候选文件列表 + 相关片段。
- 失败回退：'rg --files' + 'rg <identifier>' + 手动路径阅读。

### 5.2 'ace-tool.enhance_prompt'
- 触发：用户明确要求 '-enhance/-Enhancer' 或“enhance my prompt”或 **需求描述比较模糊或抽象** 以及 **复杂系统设计或架构问题**。
- 不触发：普通优化代码/重构请求。
- 输入最小化：只提供原始提示词与必要上下文。
- 产出预期：更明确、可执行的提示词。
- 失败回退：手工改写需求并确认关键约束。

### 5.3 'ask-user-questions.ask_user_question'
- 触发：必须收集关键业务偏好，且选项可显著改变方案。
- 不触发：可通过代码库或既有上下文推断。
- 输入最小化：2-4 个互斥可选项，附简短权衡说明。
- 产出预期：明确取舍，锁定实现方向。
- 失败回退：采用推荐默认方案并在汇报中声明假设。

### 5.4 'ask-user-questions.confirm_action'
- 触发：删除/覆盖/重置等高风险动作。
- 不触发：普通可回滚编辑。
- 输入最小化：动作、影响、回滚方式。
- 产出预期：显式确认或拒绝。
- 失败回退：停止危险动作并提供安全替代方案。

### 5.5 'context7.resolve-library-id' -> 'context7.query-docs'
- 触发：查询库/框架 API、配置、版本差异、官方最佳实践。
- 不触发：纯本地代码事实可直接确定。
- 输入最小化：库名 + 具体问题；优先官方路径。
- 产出预期：可引用的官方文档证据。
- 失败回退：官方站点手动检索 + 明确不确定性。

### 5.6 'deepwiki.read_wiki_structure'
- 触发：首次接触特定 GitHub 仓库，需要快速建立文档地图。
- 不触发：已知具体章节或实现位置。
- 输入最小化：仓库名。
- 产出预期：文档结构与主题导航。
- 失败回退：直读仓库 README/docs 目录。

### 5.7 'deepwiki.read_wiki_contents'
- 触发：需要系统阅读指定仓库文档内容。
- 不触发：仅需定点问题答案。
- 输入最小化：仓库名 + 目标主题。
- 产出预期：结构化文档摘要。
- 失败回退：手动检索官方文档与仓库源码。

### 5.8 'deepwiki.ask_question'
- 触发：针对特定仓库提定向架构/实现问题。
- 不触发：问题与目标仓库弱相关。
- 输入最小化：仓库名 + 单一聚焦问题。
- 产出预期：上下文关联回答与定位线索。
- 失败回退：本地源码搜索 + issue/discussion 检索。

我今天新增辅助邮箱时候，操作比较频繁，不太会弄，好像被我把号搞坏了，还以为是梯子问题呢。
然后现在更改邮箱也不行了。
有人遇到过吗？

最近看各种LDC的交易帖子。好像我买的贵了啊

如图，老人家手机，每次不小心打开又不知道，已经谷歌搜索未解决，希望有佬友能够解答，谢谢！