从零构建智能医院信息系统（HIS）：15个模块、23张表、68个API的全栈实战
一个覆盖 15 个业务模块、23 张数据表、68 个 API 端点的完整医院信息系统，从门诊挂号到住院结算，从药房库存到 AI 智能辅助，从医护工作台到患者自助门户。 一、项目概述医院信息系统（Hospital Information System，HIS） 是医院运营的数字中枢。本项目从零搭建了一套 Web 架构的 HIS，后端采用 Python FastAPI + SQLAlchemy 2.0（异步）+ MySQL，前端采用 Vue 3 + Vite + Element Plus，并集成了 LangChain / LangGraph 多智能体 AI 引擎，支持自然语言问诊、处方审核和智能问数。 核心数字 指标 数值 业务模块 15 个 数据库表 23 张 API 端点 68 个 用户角色 6 种（admin / doctor / nurse / cashier / pharmacist / patient） 前端页面 20+ 个 SFC 组件 二、系统架构总览1234567891...
阿里云百炼新平台语音识别踩坑全记录：从连续失败到成功的避坑指南
一句话总结：控制台能跑 ≠ 你后端能跑。前端 WebM 录音 → 百炼新平台识别，中间隔着格式、模型、SDK 三座大山，爬过去你就赢了。 前言：一周的崩溃，差点把键盘砸了做 HIS 系统开发这么多年，自认为各种第三方服务接入也算轻车熟路了。结果在阿里云百炼的新平台上搞语音识别，整整踩了一周的坑——从 “这不就是个 API 调用吗” 到 “这玩意儿到底能不能用” 的心态转变，只用了两天。 最让人崩溃的是什么？控制台上传同一个 WebM 文件，用 fun-asr 模型能正常识别，返回结果清清楚楚。 然后我信心满满地把同一个文件塞给后端接口——失败、失败、还是失败。 每次看到控制台那个绿色的识别结果，再看看自己终端里红色的报错，就一个感觉：它在嘲讽我。 这篇文章记录了我从 Transcription 异步转写到 Recognition 实时流，从自己拼 HTTP 请求到最终靠 ffmpeg 转码 + SDK 正确调用，一步步踩坑、一步步破案的全过程。如果你也在用 FastAPI + 阿里云百炼做语音识别，希望能帮你少踩几个坑。 一、先搞懂：为什么控制台能跑，我后端跑不通？核心...
Claude Code技能系统重装恢复：插件下架反而让我的架构更强大了
Claude Code技能系统重装恢复：插件下架反而让我的架构更强大了一、背景就在前几天，我重装了 Claude Code CLI。本以为只是简单的环境重建，没想到——所有自定义技能和四层架构全部丢失。更糟糕的是，当我尝试恢复原插件版技能系统时，发现官方Superpowers插件在第三方市场已经下架。 那一刻我是崩溃的。30个技能、精心设计的调度规则、用了好几个月的workflow，说没就没。 但没想到的是，这次”灾难”反而让我得到了一个更健壮、更灵活、更可控的技能系统架构。 二、恢复过程第一步：重建基础层首先恢复了顶层的 CLAUDE.md 编码规范，以及所有可以独立运行的本地单文件技能。这些是之前就已经备份好的，恢复相对顺利。 第二步：尝试安装插件（失败）当我尝试通过市场安装官方 Superpowers 插件时，发现插件已经下架。搜索、换源、手动安装……所有方法都试了一遍，确认彻底无法获取。 第三步：转为本地单文件技能Claude 自动执行了最优替代方案：将14个插件子技能全部转为本地单文件技能。每个子技能一个 SKILL.md 文件，纯文本、可编辑、零依赖。 最终结果完整...
零依赖自定义 Claude Code 状态栏：实时监控上下文、技能与会话状态
一篇面向 Claude Code 重度用户的踩坑指南，带你用纯 Python 打造一个功能完备的终端状态栏。 一、背景与痛点作为 Claude Code 的日常用户，我在 Windows 终端里一待就是几个小时。随着使用深入，有几个信息我迫切需要在状态栏里一眼看到： 当前模型与上下文 Token 使用情况 — 我经常在多个模型间切换，而且 Claude Code 的上下文窗口有限，一旦接近上限就可能截断对话，我需要一个直观的进度条来提醒自己及时 /compact 当前正在调用的代理/技能名称 — 我用子代理（sub-agent）做并行代码审查、安全审计，想知道后台正在跑什么 已加载的技能总数 — 我装了 32 个自定义技能，想知道它们是否都被正确加载 Git 分支、会话费用与耗时 — 在多项目间切换时，瞄一眼就知道自己在哪个分支上，花了多少钱 踩过的坑一开始我听说有个叫 claude-hud 的第三方插件可以做状态栏增强，但在官方插件市场找了半天也没找到。后来又尝试 claude mcp 相关的方案，同样不生效。 翻遍了 Claude Code 官方文档，终于...
智能医疗HIS系统：从FastAPI到AI多智能体的全栈实践
一个完整的医院信息系统（HIS），覆盖门诊、药房、住院、护理、收费等15个核心业务模块，并深度融合 AI 多智能体引擎实现智能分诊、处方审核和院长问数。 项目概览这是一个真正「能用」的医院信息系统——不只是 CRUD 原型，而是完整的业务闭环。后端基于 FastAPI + SQLAlchemy 2.0 + MySQL，前端使用 Vue 3 + Vite + Element Plus，AI 引擎层采用 LangGraph + LangChain + Qdrant + Redis 架构，接入阿里云百炼 Dashscope 大模型。 技术栈速览 层级 技术选型 后端框架 FastAPI (async) ORM SQLAlchemy 2.0 (aiomysql 异步驱动) 数据库 MySQL 8.0 (utf8mb4) 前端 Vue 3 + Vite + Element Plus AI 引擎 LangGraph StateGraph + LangChain 向量数据库 Qdrant (COSINE 距离, 1536 维) 缓存 Redis 7 (...
从指令到闭环：构建AI助手全自动技能生态系统的实践之路
引言用 Claude Code 一段时间后，你会发现一个尴尬的问题：它的内置能力很强，但总有些场景覆盖不到。每次遇到新领域，要么手动写 Prompt，要么临时上网搜。更难受的是——这次搜到的优质提示词，下次还得重新搜。知识不沉淀，经验不复用。 我花了几个晚上，在 Claude Code 的技能系统之上搭建了一套全自动闭环生态。核心思路很简单：让 AI 助手在遇到自己搞不定的任务时，自动去外部”学习”、自动把学到的东西”打包”成永久技能、自动纳入下一次调度的候选池。 一句话概括这条链路： 指令下发 → 主 Skill 调度 → 本地匹配 → 无匹配则自动拉取 prompts.chat 提示词 → 生成并保存为本地子 Skill → 纳入调度池 → 长期迭代优化 下面详细拆解每一步的设计与实现。 一、架构总览：一个主入口，多重能力池整个系统分为三层： 12345678910111213141516171819202122┌──────────────────────────────────────────────┐│ 用户指令（自然语言） ...
An_Skills管理方案
背景Claude Code 的 Skills 生态很强大，但技能多了之后会出现两个问题： 上下文膨胀 — 每个 Skill 的完整描述都会注入 System Prompt，24 个 Skill 轻松吃掉几千 token 匹配混乱 — 多个 Skill 的关键词重叠时，模型可能选错 我的解决方案：单入口 + 分级可见。 架构设计12345用户请求 → my-ai-assistant（主入口，on） │ ├── 自动语义匹配 ──→ 核心子 Skill（name-only） │ └── 手动调用 ──→ 其他子 Skill（/技能名） 核心机制：skillOverridesClaude Code 的 settings.json 中有一个 skillOverrides 字段，控制每个 Skill 的可见级别： 模式 含义 on 完整加载：名称 + 描述 + 可调用 name-only 仅名称：模型看得到名字，占极少 token user-invo...
Hexo 博客搭建踩坑记录
从零搭建一个 Hexo + Butterfly + GitHub Pages 博客，看着简单，实操下来还是踩了不少坑。这篇文章把过程中遇到的问题和解决方案整理出来，给同样在折腾的人一个参考。 环境准备Node.js 和 Git 是前提，版本别太老就行： 123node --version # v18+git --version # 2.x+npm --version 这一步基本不会出问题，跳过。 坑 1：Hexo 初始化目录必须为空这是第一个低级错误。hexo init 要求目标目录是空文件夹，如果你提前建了目录并往里放了东西，init 会失败。 正确姿势： 123mkdir my-blogcd my-bloghexo init . 或者让 Hexo 自己建目录： 123hexo init my-blogcd my-blognpm install 坑 2：主题配置文件到底在哪改Butterfly 主题安装完后，配置文件的加载优先级是这样的： _config.butterfly.yml（项目根目录，优先级最高） themes/butterfly/_config.y...
我的第一个 Hexo 博客上线了
折腾了两天，我的 Hexo 博客终于上线了。从零到一，踩了不少坑，写篇文章记录一下。 为什么选 Hexo需求很简单：静态博客、Markdown 写作、免费托管、能自定义主题。WordPress 太重，Notion 不够 geek，选了一圈最后锁定了 Hexo + GitHub Pages。Node.js 生态、中文社区活跃、Butterfly 主题颜值在线，够了。 环境配置，比想象的顺Node.js 和 Git 都是现成的，三条命令就起跑了： 123npm install -g hexo-clihexo init my-blogcd my-blog && npm install hexo s 跑起来，localhost:4000 看到默认页面的那一刻，还是有点小激动的。 主题选了 Butterfly默认 Landscape 太素了，对比了几个热门主题后选了 Butterfly。好看，配置项多，中文文档完整。 1npm install hexo-theme-butterfly --save 改 _config.yml 里一行： 1theme: butterf...