人工智能，已为吾辈撰述软件之常道。其能读码，献策补漏，释疑解惑，速逾多数Stack Overflow之答。然犹有之事，非其独能：察吾辈之实据。
此实为较之常情更甚之困。
而能实察之虫豸助人者
汝得哨兵警报。汝将堆栈轨迹粘贴于克劳德。其错误、其参数、其行号。彼读之尽，妄测其故。
然其弊在于此。不过臆测耳。彼不知用户记录之状。彼不知关联对象之态。彼不知此乃偶发之故，抑或众用户恒于此聚。
汝遂为是物之手足。运行查询，复将结果粘贴，再行数事。此流程非至劣，然AI可为之半事，今未尽其能也。
若以MCP服务器联于汝之Rails应用，则可自察。其能述汝之模型，引相关记录，复报若此："遇此谬误者，皆onboarding_completed_at为空，而"subscription_active诚然。观其流程，似有缺环。无往复，无复制粘贴查询结果。
汝之AI驱使之少吏
同疾异境：尔三月前已发一功能，今产品部有人欲知其是否实用。
此常需撰一查询，构一简报，或向执掌分析者呈一票。此皆非难事，然其间阻隔，致所问多寂寂而亡，少有得解。
若数据可通过MCP得见，汝但问之。"近三十日内，几何用户已用新导出之功能？依计划分之。" 调用适器，计数归组，应答若瞬。无SQL，无仪表盘，无久候。
此乃知码库之AI与识产线实况之AI之别。
何不直予其数据库URL？
善问也。简言之，直取数据库即直用SQL，直用SQL则无所不可。或越表联结非所宜联，或询主库而非副库，或无记所取之迹。
activerecord-mcp则使AI由应用层得入。询则经ActiveRecord，以哈希条件验实列名。敏感之列如password_digest、令牌及密钥，于数据触及数据库之前，即遭正则拒止列表所阻，于输出之际亦被剥离，以防万一。凡事皆以只读角色运行，此乃默认之规。OAuth 2.1令牌限权，使MCP凭据不得渗漏至堆栈之他处。
此即汝应施于任何内部API之访问控制，亦施于汝之AI工具。
启程之始
# Gemfile
gem "activerecord-mcp"
gem "doorkeeper"
bundle install
bin/rails generate doorkeeper:install
bin/rails generate doorkeeper:migration
bin/rails db:migrate
bin/rails generate rails_mcp:install
限其所欲显之模，挂之，而联之：
claude mcp add --transport http my-app https://your-app.com/mcp \
--header "Authorization: Bearer $MY_APP_TOKEN"