AI

看到个项目，code graph，顾名思义应该是把项目代码给构建成图谱，拖延到今天来实测一下效果 仓库地址：GitHub - colbymchenry/codegraph: Pre-indexed code knowledge graph for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, and Hermes Agent — fewer tokens, fewer tool calls, 100% local · GitHub 安装 code graph mac 安装命令 1 curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh 安装 MCP 配置 初始化项目 进入一个最近在开发的目录，开始索引 1 2 cd your-project codegraph init -i 接下来他会扫描仓库的文件并且在本地新建数据库 大概流程是这样的： 显示已折叠代码（21 行） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 你的代码目录 │ ▼ Tree-sitter 解析源码 │ ▼ 抽取符号(Symbol) 函数、类、方法、变量、路由 │ ▼ 分析关系(Edge) 调用关系 继承关系 导入关系 引用关系 │ ▼ 写入 SQLite │ ▼ 生成 .codegraph/ 官方文档里提到，CodeGraph 会把符号、调用图、文件结构等信息存到 SQLite（FTS5）数据库中，并把项目数据放在 .codegraph/ 目录下。 ...

本文转载自 Datawhale easy-vibe 教程，加了自己的理解和全链路自建的部分 手机上写代码？ 地铁上突然想到一个 bug 怎么修，买一杯瑞排队的时候收到线上告警，躺床上不想起来但又想让 Claude 帮你跑个任务——这种场景太多了。传统 IDE 那套东西在手机上根本跑不动，虚拟键盘输入代码效率低得离谱，小屏幕连代码和终端都放不下。 但换个思路想，手机只需要当一个控制台就够了——输入指令、看结果、审批操作。真正干活的还是你家里/公司的开发机。 这就是"瘦客户端"的核心思想：手机只管发指令，活在别处干。 现有方案快速过一遍 社区里能用的方案其实不少了，快速过一下： iOS 官方 App Anthropic 出的 Claude App 里直接有 Code 标签页。手机发指令，代码在 Anthropic 云端沙盒执行，结果通过 GitHub 同步。零配置，Pro 订阅就能用。但——中国大陆用不了，功能也受限，不能访问本地文件系统。pass。 Happy Coder 开源的，跨平台（iOS/Android/Web），端到端加密。电脑上装个 happy-coder，手机扫码配对就能远程控制 Claude Code 和 Codex。配置简单，扫码即用，这个方案用的人很多。 但连接不太稳定，断线了上下文就丢了。而且依赖第三方中继服务器，代码安全心里没底。 SSH + Tailscale + Tmux 最硬核的方案。Tailscale 做 VPN 打洞（打洞失败自动中继），手机用 SSH 客户端连上开发机，Tmux 保持会话不丢。功能最完整，桌面级体验。但配置复杂，电脑得一直开着，还得会 Tmux。适合老手。 Termux Android 用户可以在手机上直接跑 Claude Code CLI。装个 Termux（注意从 F-Droid 下，Google Play 版本过时了），装 Node.js，装 Claude Code，完事。手机性能有限，编译大型项目就算了，但写个 Python 脚本、跑个 Web 项目还是没问题的。仅限 Android。 ...

原文：AI 输出中的 ** 是怎么来的：谈中文 Markdown 强调标记的渲染问题 作者：PlatyHsu 发布时间：2026-04-17 18:01（UTC+8） 说明：这里不做全文转载，只做摘要整理和少量引用；完整内容请回原站阅读。 最近看少数派这篇文章，刚好把一个平时经常见到、但很少认真追根溯源的问题讲透了： 为什么 AI 明明吐出了 Markdown 的 **，结果中文里的加粗却没有生效？ 比如下面这种内容，我们大概都见过： 1 2 **重要：**请注意。 这是**「重要」**的内容。 看起来像是标准 Markdown，但不少渲染器最后会把 ** 原样显示出来，而不是变成粗体。 这篇文章讲了什么 原文的核心观点很简单： 早年的原版 Markdown 规则其实比较“松”，很多中文场景下反而能正常加粗。 现在更主流的实现，大多跟随 CommonMark 规范。 CommonMark 为了避免误判数学式、变量名等内容，引入了更严格的“贴合”规则。 这套规则主要按英文的分词和标点习惯设计，对中文这种不依赖空格分词的文本并不友好。 所以问题不在 AI，也不在你写错了 **，而在于很多现代 Markdown 渲染器对“强调”这件事判断得更严格了。 为什么中文里更容易出问题 原文提到，CommonMark 在处理强调标记时，会判断一串 * 或 _ 是否满足“左侧贴合”和“右侧贴合”。 说人话就是： 开始的强调标记，后面最好直接跟文字，或者某些“起始型”标点。 结束的强调标记，前面最好直接跟文字，或者某些“结束型”标点。 这套思路放在英文里比较自然，因为英文大量依赖空格来分隔词语和标点位置；但到了中文里，文字之间本来就没有空格，于是像中文冒号、书名号、引号这样的场景，就很容易让强调判断失败。 也就是说，下面这两种写法在不少 CommonMark 系实现里都可能失效： 1 2 **重要：**请注意。 这是**「重要」**的内容。 前者的问题在 ：，后者的问题在 「」 这种中文标点环境。 原文给出的几种解决办法 1. 直接改用 HTML 标签 这是最直接、也最稳的办法： ...